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内 容 简 介 


本 书 从 一 位 资深 PostgreSQL 专家 在 多 年 咨询 、 技 术 支 持 工作 中 的 切身 体会 出 发 ， 深 入 介绍 了 开源 数据 
库 管 理 系统 PostgreSQL 9.6 版 本 中 的 主要 特性 ， 其 内 容 涵盖 了 作为 一 个 PostgreSQL 数据 库 从 业 人 员 经 常会 
接触 到 的 主题 : 事务 和 锁定 、 索 引 的 使 用 、 高 级 SQL 处 理 、 日 志文 件 和 统计 信息 、 查 询 优化 、 存 储 过 程 、 
安全 性 、 备 份 与 恢复 、 复 制 、 各 类 扩展 、 故 障 排查 、 系 统 迁移 。 作 者 通过 亲身 经 历 和 直观 的 例子 ， 详 细 介 
绍 了 PostgreSQL 主要 特性 的 工作 原理 、 常 用 配置 以 及 常见 的 误区 , 是 一 本 实用 性 很 强 的 PostgreSQL 进 阶 指 
南 ， 能 帮助 有 一 定 PostgreSQL 知识 的 读者 深入 了 解 PostgreSQL 中 更 多 更 全 面 的 高 级 特性 。 

本 书 适 合 数据 库 管理 人 员 和 开发 人 员 了 解 和 学 习 PostgreSQL。 通 过 阅读 本 书 ， 读 者 可 以 对 PostgreSQL 
有 一 个 全 面 透彻 的 了 解 。 

Copyright © Packt Publishing 2017.First published in the English language under the title 
Mastering PostgreSOL 9.6 
Simplified Chinese-language edition © 2018 by Tsinghua University Press. All rights reserved. 

本 书 中 文 简体 字 版 由 Packt Publishing 授权 清华 大 学 出 版 社 独 家 出 版 。 未 经 出 版 者 书面 许可 ， 不 得 以 任 

何方 式 复制 或 抄袭 本 书 内 容 。 
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关于 作者 


Hans-JuDrgen Sch6nig 拥有 18 年 的 PostgreSQL 经 验 ， 是 一 家 名 为 Cybertec Schonig & 
Sch5nig GmbH (www.postegresql-support.de) 的 PostgreSQL 咨询 和 支持 公司 的 CEO。 该 公 
司 已 经 成 功 地 为 全 球 数 不 尽 的 客户 提供 了 服务 。 

在 2000 年 创建 Cybertec Sch5nig & Sch6nig GmbH 之前， 他 是 一 家 专注 于 奥地利 劳动 
市 场 的 私营 调查 公司 的 数据 库 开 发 人 员 ， 当 时 他 的 主要 工作 是 数据 挖掘 和 预测 模型 。 他 
已 经 写 了 好 几 本 有 关 PostgreSQL 的 书 。 


关于 审 稿 人 


Shaun Thomas 从 2000 年 年 末 开 始 从 事 PostgreSQL 的 工作 。 从 2011 年 开始 ， 他 已 经 
成 为 PostgresOpen 大 会 的 常客 ， 并 且 在 大 会 上 多 次 发 表 了 关于 如 何 处 理 极限 吞吐 、 高 可 
用 性 、 监 控 、 架 构 和 自动 化 方面 的 演讲 。 他 贡献 了 一 些 PostgreSQL 扩展 以 及 一 种 管理 大 
规模 数据 库 集 群 的 工具 。 有 时 ， 他 也 在 本 地 大 学 里 担任 客座 讲师 。 他 的 目标 是 帮助 社区 
把 PostgreSQL 打造 成 一 种 更 大 、 更 好 的 数据 库 ， 让 每 个 人 都 乐 在 其 中 。 
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您 是 否 了 解 Packt 为 每 一 本 出 版 的 书籍 都 提供 了 电子 书 版 本 (有 PDF 和 ePub 文件 可 
1 ) ? 您 可 以 在 www.PacktPub.com 上 升级 为 电子 书 版 本 ， 并 且 作为 一 位 实体 书 客户 ， 您 
可 以 在 电子 书 备 份 上 享受 到 折扣 。 详 情 请 通过 service@packtpub.com 与 我 们 联系 。 
在 www.PacktPub.com 上 ， 您 还 可 以 阅读 一 些 免费 技术 文章 ， 请 注册 一 系列 免费 通 
言 ， 这 样 可 以 接收 Packt 实体 书 和 电子 书 的 专 享 折扣 和 特 供 。 
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客户 反馈 


感谢 购买 这 本 由 Packt 出 版 的 书 。 在 Packt， 质 量 是 我 们 编辑 处 理 的 中 心 任务 。 为 了 
帮助 我 们 提高 ， 请 在 本 书 的 Amazon 页 面 https://www.amazon.com/dp/1783555351 上 留 下 
您 中 肯 的 评价 。 

如 果 您 愿意 加 入 我 们 的 正式 评阅 团队 ， 您 可 以 发 邮件 到 customerreviews@packtpub.com。 
我 们 将 向 正式 评阅 人 回馈 免费 的 电子 书 和 视频 来 奖励 他 们 有 价值 的 反馈 。 请 毫 无 保留 地 
帮助 我 们 提高 我 们 的 产品 ! 








译 者 序 


PostgreSQL 是 一 种 历史 悠久 的 开源 对 象 关系 型 数据 库 管理 系统 ， 它 不 仅 支持 关系 型 
数据 库 的 各 种 功能 ， 而 且 还 具备 类 、 继 承 等 对 象 数 据 库 的 特征 。 这 个 起 源 于 加 州 大 学 伯 
克利 分 校 (UCB ) 的 数据 库 研 究 计 划 ， 目 前 已 经 衍生 成 一 项 国际 开发 项 目 ， 并 且 拥 有 越 
来 越 广泛 的 用 户 群 以 及 越 来 越 多 的 应 用 案例 。 

本 书 根据 一 位 资深 PostgreSQL 专家 多 年 的 从 业经 验 ， 深 入 介绍 了 开源 数据 库 管 理 系 
统 PostgreSQL 的 主要 特性 。 其 内 容 涵 盖 了 数据 库 用 户 日 常 工作 中 经 常会 接触 到 的 话题 ， 
包括 并 发 控制 、 索 引 、 高 级 SQL 处 理 、 日 志和 统计 、 查 询 优化 、 存 储 过 程 、 安 全 性 、 高 
可 用 等 。 对 于 日 益 增 长 的 PostgreSQL 用 户 群体 来 说 ， 这 是 一 部 难得 的 好 书 。 

在 本 书 的 翻译 过 程 中 ， 除 译 者 之 外 ， 彭 钰 杰 、 段 芳 、 段 亮 圩 、 兰 海 、 韩 珂 、 部 凌 
翔 、 吴 瑕 、 李 宇 瑞 、 何 子 龙 、 段 辉 银 、 王 淞 、 赖 思 超 、 龙 德 秀 、 罗 倩 去 、 徐 明 民 、 王 
敏 、 天 名 亮 、 汪 佳 、 彭 文 汉 、 熊 春 娥 等 人 也 参与 了 本 书 的 翻译 工作 ， 在 此 一 并 表示 

限于 译 者 的 水 平 ， 译 文中 难免 有 错误 和 不 妥 之 处 ， 奶 请 广大 读者 批评 指正 。 





彭 煜 玮 
2017 年 12 月 17 日 于 歼 珈 山 

















推荐 序 一 


从 互联 网 、 移 动 互联 网 到 互联 网 +， 再 到 IoT、 万 物 互 联 、 人 工 智能 ， 只 用 数 十 年 计 
算 机 就 从 科技 行业 渗透 到 了 几乎 所 有 的 传统 行业 : 线 上 线 下 打通 ， 甚 至 将 来 会 完全 融 
合 。 由 于 企业 数据 爆炸 性 增长 ， 数 据 库 在 整个 变革 中 承担 了 非常 重要 的 角色 ， 掀 起 了 数 
据 驱 动 的 狂潮 。 

PostgreSQL 数据 库 凭借 丰富 的 功能 、 强 大 的 扩展 接口 能 力 、 稳 定 的 数据 库 内 核 正 风 
靡 全 球 ， 在 互联 网 、 金 融 、 物 联网 、 传 统 企业 等 行业 占据 越 来 越 重 要 的 地 位 。 全 球 数 据 
库 权威 评测 网 站 DB-Ranking 的 评测 结果 来 看 ，PostgreSQL 最 近 几 年 在 所 有 数据 库 产 品 中 
发 展 是 最 为 迅猛 的 ， 同 时 新 出 的 PG 相关 书籍 已 达 数 百 本 之 多 。 

本 书 作 者 是 具有 18 年 PG (PostgreSQL) 数据 库 经 验 的 国外 大 牛 ， 本 书 的 内 容 非常 丰 
满 。 (1) 原理 讲解 深入 浅 出 ， 将 官方 手册 中 较 难 理解 的 内 容 简单 明了 地 展示 给 读者 ， 适 
合 DBA、 架 构 师 阅读 。 (2) 在 SQL 部 分 给 读者 讲解 了 SQL 高 级 用 法 、 存 储 过 程 的 开 
发 ， 掌 握 这 些 用 法 可 以 在 实际 工作 中 大 大 降低 开发 工作 量 ， 轻 松 实现 较 高 难度 的 业务 需 
求 ， 建 议 开发 者 、 数 据 分 析 师 阅读 。 (3) 讲解 了 数据 库 安全 、 备 份 恢复 、 排 错 、 优 化 ， 
适合 DBA 阅读 。 (4) PostgreSQL 扩展 接口 丰富 ， 本 书 在 数据 库 扩展 包 部 分 给 读者 展示 
了 常用 的 扩展 包 ， 以 及 扩展 包 的 开发 方法 ， 适 合 开发 者 、 架 构 师 阅读 。 (5) 本 书 还 包含 
了 迁移 部 分 ， 帮 助 读者 了 解 如 何 从 异 构 数据 库 〈 如 Oracle、SQL Server 等 ) 、 同 构 数据 库 
迁移 到 PostgreSQL。 

译 者 彭 煜 玮 先生 ， 武 汉 大 学 计算 机 学 院 副 教授 ， 是 我 多 年 的 良师益友 ， 同 时 也 是 
PostgreSQL 中 国 社区 的 核心 成 员 。 他 培养 输出 的 数据 库 人 才 不 尽 其 数 ， 他 们 分 布 在 阿里 
巴巴 、 华 为 、 腾 讯 等 企业 ， 推 动 了 中 国 数据 库 行 业 的 发 展 。 

期 待 新 书 早 日 面世 ， 加 快 PostgreSQL 在 国内 开发 人 员 、DBA、 数 据 分 析 师 、 架 构 师 
等 从 业 人 和 群 中 的 普及 ， 将 其 应 用 到 更 多 的 企业 ， 实 现 技 术 为 业务 服务 的 转化 。 











周正 中 
阿里 云 高 级 技术 专家 
2018 年 9 月 


推荐 序 二 


数据 库 技 术 出 现 于 20 世纪 60 年 代 中 后 期 ， 堪 称 电 子 计 算 机 领域 最 古老 的 技术 之 
一 。 自 诞生 至 今 ， 数 据 库 几乎 是 每 一 个 “严肃 ”应 用 不 可 或 缺 的 一 部 分 。 在 这 几 十 年 的 
演进 过 程 中 ， 数 据 库 领 域 发 生 过 很 多 “有 趣 ” 的 技术 对 抗 ， 包 括 网 状 模型 与 关系 模型 之 
争 、 关 系数 据 库 与 XML 数据 库 之 争 、NoSQL 与 SQL 之 争 等 。 直 到 现在 ， 数 据 库 技术 还 
是 最 前 沿 的 计算 机 技术 之 一 ， 无 论 工业 界 还 是 学 术 界 ， 数 据 库 相关 的 研究 和 开发 都 非常 
活跃 。 近 十 年 ， 伴 随 着 大 数据 处 理 需 求 的 发 展 ， 数 据 库 领域 出 现 多 种 探索 和 变迁 ， 某 些 
趋势 逐渐 明朗 起 来 。 趋 势 之 一 是 SQL 作为 大 数据 处 理 的 “万 向 头 ” 被 广泛 接受 ， 这 可 以 
从 很 多 NoSQL 开始 支持 SQL 得 到 印证 ; 另外 一 个 趋势 是 向 事务 型 、 分 析 型 混合 处 理 
(HTAP) 发 展 。 

PostgreSQL 是 最 成 熟 最 先进 的 开源 SQL 数据 库 之 一 ， 其 OLTP 处 理 能 力 强大 。 近 几 
年 在 OLAP 方面 也 有 长 足 发 展 ， 包 括 多 核 优化 、 并 行 处 理 、 分 区 表 等 特性 。PostgreSQL 
扩展 能 力 强大 ， 通 过 扩展 可 以 处 理 各 种 各 样 的 数据 ， 辟 如 流 式 数 据 、 时 间 序 列 数 据 、 地 
理 信息 数据 等 。 还 有 很 多 项 目 以 PostgreSQL 为 基础 构建 分 布 式 数据 库 。 总 而 言 之 ， 
PostgreSQL 功能 强大 、 社 区 活跃 、 发 展 前 景 广阔 ， 是 一 款 很 值得 投资 学 习 的 数据 库 。 

本 书 全 面 介 绍 了 PostgreSQL 数据 库 日 常 进 阶 管理 的 各 个 方面 ， 提 供 了 大 量 的 实例 以 
方便 读者 实践 。 此 外 作者 还 阐述 了 很 多 实战 中 总 结 的 心得 和 技巧 。 译 者 具有 多 年 的 
PostgreSQL 教学 、 实 操 和 内 核 开发 经 验 ， 对 原 书 理解 透彻 ， 语 言 流 畅 准 确 。 感 谢 作 者 和 
译 者 为 PostgreSQL 社区 贡献 这 样 一 本 出 色 的 书籍 。 

“至 哉 天 下 乐 ， 终 日 在 几 案 ”， 祝 大 家 阅读 愉快 。 


姚 延 栋 
Pivotal 中 国 Greenplum 研发 总 监 
2018 年 9 月 


了 


前 


PostgreSQL 是 一 种 开源 数据 库 管理 工具 ， 它 可 以 被 用 于 处 理 大 型 数据 集 (大 数据 ) 
并 且 可 以 被 用 作 一 种 JSON 文档 数据 库 。 它 也 在 软件 和 Web 领域 中 有 很 多 应 用 。 本 书 将 
让 读者 能 够 构建 更 好 的 PostgreSQL 应 用 并 且 更 有 效 地 管理 数据 库 。 


本 书 所 涵盖 的 内 容 


第 1 章 PostgreSQL 概述 ， 使 读者 从 总 体 上 了 解 PostgreSQL 及 其 特性 。 读 者 将 学 到 
PostgreSQL 中 可 用 的 新 事物 和 新 功能 。 

第 2 章 理解 事务 和 锁定 ， 将 涵盖 任意 数据 库 系统 最 重要 的 方面 之 一 。 没 有 事务 的 存 
在 ， 数 据 库 通常 无 法 正确 地 工作 。 因 此 理解 事务 和 锁定 对 于 性 能 以 及 专业 工作 来 说 都 是 
很 关键 的 。 

第 3 章 使 用 索引 ， 涵 盖 了 读者 需要 了 解 的 与 索引 有 关 的 方方面面 。 索 引 是 性 能 的 关 
键 因 素 ， 因 此 它 是 获得 良好 用 户 体验 和 高 吞吐 量 的 重要 基石 。 索 引 的 所 有 重要 方面 都 会 
在 本 章 中 被 涵盖 。 

第 4 章 处 理 高 级 SQL， 将 介绍 现代 SQL 的 一 些 最 重要 的 概念 。 读 者 将 学 到 窗口 函数 
以 及 其 他 重要 的 更 现代 化 的 SQL。 

第 5 章 日 志文 件 和 系统 统计 信息 ， 将 引导 读者 通过 更 多 管理 任务 ， 例 如 日 志文 件 管 
理 和 监控 。 读 者 将 学 到 如 何 观 察 其 服务 器 并 且 从 PostgreSQL 中 提取 运行 时 信息 。 

第 6 章 优化 查询 获得 良好 性 能 ， 将 告诉 读者 所 有 有 关 良 好 PostgreSQL 性 能 的 内 容 。 
本 章 将 涵盖 SQL 调 优 以 及 内 存 管理 的 信息 。 

第 7 章 编写 存储 过 程 ， 教 会 读者 与 服务 器 端 代码 相关 的 更 高 级 的 主题 。 本 章 涵盖 最 
重要 的 服务 器 端 编程 语言 及 其 他 重要 的 方面 。 

第 8 章 管理 PostgreSQL 安全 性 ， 本 章 的 目的 是 帮助 读者 提高 服务 器 的 安全 性 。 本 章 
会 介绍 从 用 户 管理 到 行 级 安全 性 的 各 种 特性 。 有 关 加 密 的 内 容 也 包括 在 本 章 中 。 

第 9 章 处 理 备份 和 恢复 ， 涵 盖 有 关 备 份 和 数据 恢复 的 所 有 内 容 。 读 者 将 学 到 备份 其 
数据 以 及 在 遇 到 灾难 时 恢复 数据 。 

第 10 章 理解 备份 和 复制 ， 本 章 与 元 余 有 关 。 读 者 将 学 到 异步 以 及 同步 复制 
PostgreSQL 数据 库 系统 。 本 章 将 尽 可 能 全 面 地 介绍 所 有 的 现代 特性 。 

第 11 章 选 定 有 用 的 扩展 ， 本 章 描述 对 PostgreSQL 增加 额外 功能 的 被 广泛 使 用 的 模 























mt 
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块 。 读 者 将 学 到 最 常见 的 扩展 。 

第 12 音 在 PostgreSQL 中 排查 错误 ， 本 章 提供 了 一 种 系统 的 方法 以 修复 PostgreSQL 
中 的 问题 。 它 将 使 读者 能 够 定位 常见 的 问题 并 且 以 一 种 有 条 理 的 方式 解决 问题 。 

第 13 章 迁移 到 PostgreSQL， 它 是 本 书 的 最 后 一 章 并 且 向 读者 展示 了 从 商业 数据 库 到 
PostgreSQL 的 路 径 。 本 章 将 涵盖 当今 能 被 迁移 的 最 重要 的 数据 库 。 

需要 的 预备 知识 


本 书 的 读者 很 广泛 。 为 了 能 跟 得 上 本 书 中 给 出 的 例子 ， 至 少 要 有 一 些 SQL 甚至 
PostgreSQL 的 经 验 (不 过 这 并 非 硬 性 要 求 )。 一 般 来 说 ， 如 果 能 熟悉 Unix 命令 行 会 更 好 。 
适合 人 群 
本 书 是 为 那些 想 要 对 PostgreSQL 了 解 更 多 并 且 不 满足 于 基本 知识 的 人 而 写 。 其 目标 
是 写 一 本 更 加 深入 的 书 ， 并 且 以 一 种 清晰 且 易 懂 的 方式 解释 最 重要 的 内 容 。 
本 书 约定 
在 本 书 中 ， 读 者 将 会 找到 几 种 区 分 不 同类 别 信息 的 文本 样式 。 这 里 有 这 些 样式 的 一 
些 例子 及 其 含义 的 解释 。 
任何 命令 行 输入 或 者 输出 都 被 写 为 下 面 这 样 : 
test=# CREATE TABLE t test(id serial, name text); 
CREATE TABLE 


test=# INSERT INTO 七 test (name) SELECT 'hans' 
FROM generate series (1，2000000) 7 


新 术语 和 重要 的 词 被 加 粗 。 








0 警告 或 重要 的 注 记 出 现在 一 个 这 样 的 框 中 。 


6 提示 和 技巧 以 这 种 形式 出 现 。 


读者 反馈 


我 们 非常 欢迎 来 自 读 者 的 反馈 。 请 让 我 们 知道 您 对 本 书 的 想法 一 一 不 管 您 喜欢 还 是 不 
喜欢 这 本 书 。 读 者 反馈 对 我 们 来 说 非常 重要 ， 它 能 帮助 我 们 开发 对 读者 真正 有 用 的 主题 。 

如 果 要 向 我 们 发 送 一 般 的 反馈 ， 请 写 邮件 到 feedback@packtpub.com， 并 且 在 邮件 的 
主题 中 提 及 本 书 的 标题 。 
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如 果 您 在 一 个 主题 上 拥有 专业 的 知识 ， 并 且 有 兴趣 写作 或 者 为 著 书 做 出 贡献 ， 请 参 
考 我 们 的 作者 指南 : www.packtpub.com/authors。 


客户 支持 


现在 您 已 经 自豪 地 拥有 了 一 本 由 Packt 出 版 的 书 ， 我 们 有 很 多 措施 来 帮助 您 最 大 限度 
地 从 本 次 购买 中 受益 。 


勘误 表 


尽管 我 们 已 经 非常 细心 地 确保 内 容 的 准确 性 ， 但 错误 仍 可 能 出 现 。 如 果 您 在 我 们 的 
书籍 中 找到 了 错误 ， 有 可 能 是 文字 或 者 代码 的 错误 ， 请 您 将 错误 报告 给 我 们 ， 我 们 将 不 
胜 感激 。 这 样 做 可 以 让 其 他 读者 免 受 错误 的 干扰 并 且 能 帮助 我 们 改进 本 书 的 后 续 版 本 。 
如 果 您 找到 任何 勘误 ， 请 通过 访问 http://www.packtpub.com/submit-errata 并 报告 : 选择 相关 
的 书 ， 单 击 Errata Submission Form 超 链 接 ， 然 后 输入 勘误 的 详情 。 一 旦 您 的 勘误 被 确认 ， 
您 的 提交 将 被 接受 并 且 那 些 勘 误 将 被 上 传 至 我 们 的 网 站 或 者 被 加 入 到 该 书 的 勘误 表 中 。 

如 果 要 查看 之 前 提交 的 勘误 表 ， 可 以 访问 https:/www.packtpub.comy/books/content/ 
support 并 且 在 搜索 区 中 输入 该 书 的 名 字 。 要 检索 的 信息 将 出 现在 Errata 部 分 。 


盗版 

互联 网 上 对 受 版 权 保护 的 材料 被 盗版 行为 是 所 有 媒体 都 面临 着 的 问题 。 在 Packt， 我 
们 非常 重视 对 我 们 的 版 权 和 许可 证 的 保护 。 如 果 您 在 互联 网 上 发 现任 何 形式 的 对 我 们 作品 
的 非法 复制 ， 请 立即 向 我 们 提供 位 置地 址 或 者 网 站 名 称 ， 这 样 我 们 可 以 对 其 进行 纠正 。 

请 通过 copyright@packtpub.com 联系 我 们 并 提供 疑似 盗版 材料 的 链接 。 

感谢 您 在 保护 我 们 的 作者 和 为 读者 提供 有 价值 内 容 的 能 力 方面 提供 的 帮助 。 

问题 

如 果 读 者 对 本 书 的 任何 方面 有 疑问 ， 可 以 通过 questions@packtpub.com 联系 我 们 ， 我 
们 将 尽力 为 读者 解决 。 
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PostgreSQL 是 世界 上 最 先进 的 开源 数据 库 系 统 之 一 ， 它 拥有 很 多 被 开发 者 和 系统 管 
理 员 广泛 使 用 的 特性 。 在 本 书 中 将 介绍 其 中 的 酷 炫 特性 并 且 讨论 它们 的 细节 。 

在 本 章 中 ， 笔 者 将 介绍 PostgreSQL 以 及 其 9.6 之 后 版 本 中 的 新 特性 ， 所 有 相关 的 新 
功能 都 将 被 详细 地 介绍 。 鉴 于 PostgreSQL 代码 的 变化 量 巨 大 且 整 个 项 目 也 很 庞大 ， 这 里 
介绍 的 特性 列表 当然 没 法 做 到 面面俱到 ， 因 此 笔者 将 尝试 把 重心 放 在 对 大 多 数 人 都 是 最 
重要 的 特性 上 。 

本 章 介绍 的 特性 将 被 分 为 以 下 几 类 : 
数据 库 管 理 。 

SQL 和 开发 相关 。 
备份 、 恢 复 和 复制 。 
性 能 相关 的 主题 。 


1.1 PostgreSQL 9.6 中 有 什么 新 技术 


PostgreSQL 9.6 发 布 于 2016 年 年 末 ， 它 是 遵循 PostgreSQL 旧 的 版 本 编号 方式 的 最 后 
一 个 版 本 ， 这 种 版 本 编号 方式 已 经 使 用 了 十 几 年 。 从 PostgreSQL 10.0 开始 将 会 采用 一 种 
新 的 版 本 编号 系统 。 从 10.0 开始 ， 主 发 行将 会 变 得 更 加 频繁 。 


1.1.1 理解 新 的 数据 库 管理 功能 
PostgreSQL 9.6 有 很 多 新 特性 能 够 帮助 管理 员 减 轻 工 作 负担 并 且 让 系统 更 加 鲁 棒 。 


其 中 之 一 是 idle_ in transaction_session_timeonut 功能 。 
1， 杀 掉 闲 置 会 话 


在 PostgreSQL 中 ， 一 个 会 话 或 者 事务 基本 上 可 以 近乎 永远 生存 。 在 某 些 情况 下 ， 事 
务 存在 太 久 会 导致 问题 。 通 常 ， 这 种 情况 都 是 由 于 缺陷 而 产生 的 。 其 问题 在 于 : 不 正常 
的 长 事务 会 导致 清理 出 现 问 题 并 且 可 能 会 发 生 表 膨 胀 。 失 控 的 表 增长 〈 膨 胀 ) 自然 就 会 
导致 性 能 问题 ， 进 而 引起 最 终 用 户 的 不 快 。 

从 PostgreSQL 9.6 开始 ， 可 以 限制 一 个 无 所 事 事 的 事务 内 部 所 耗费 的 数据 库 连 接 时 
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间 。 例 如 : 


test=# SET idle in transaction session timeout TO 2500; 
SET 
test=# BEGIN; 
BEGIN 
test=# SELECT 1; 
?column? 


(1 row) 
test=# SELECT 1; 
FATAL: terminating connection due to idle-in-transaction timeout 


管理 员 和 开发 者 可 以 设置 一 个 超时 时 间 ， 在 笔者 的 例子 中 设置 为 2.5 秒 。 只 要 一 个 事 
务 空 闲 过 久 ， 服 务 器 会 自动 中 止 该 连接 。 这 样 ， 长 空闲 事务 带 来 的 令 人 不 快 的 副作用 就 
可 以 通过 调整 这 个 参数 轻松 解决 。 

2， 在 pg_stat_activity 找到 更 详尽 的 信息 

pg_stat_activity 功能 是 一 个 已 经 存在 了 很 多 年 的 系统 视图 ， 它 主要 包含 了 一 个 活动 连 
接 的 列表 。 在 老 版 本 的 PostgreSQL 中 ， 管 理 员 能 够 看 到 一 个 查询 正在 等 待 其 他 人 ， 但 是 
没 办 法 查 出 这 个 查询 为 什么 等 待 以 及 在 等 待 谁 。 在 9.6 中 这 种 状况 得 到 了 改变 ，pg_stat_ 
activity 中 增加 了 两 个 列 : 


test=# \d pg_stat activity 
View "pg_catalog.pg stat activity" 


Column 1 Type | Modifiers 
六 ER RE 
wait event type | text 
wait event | text 


除 这 种 扩充 外 ，9.6 中 还 增加 了 一 个 新 的 过 程 ， 它 可 以 显示 谁 导致 了 谁 等 待 : 


test=# SELECT * FROM pg blocking pids(4711); 
pg blocking pids 


{3435} 
(1 row) 


当 这 个 过 程 被 调用 时 ， 它 会 返回 一 个 导致 指定 进程 阻塞 的 PID 列表 。 
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3， 跟 踪 vacuum 进度 


很 多 年 来 ， 人 们 都 在 要 求 增 加 一 个 用 于 vacuum 的 进度 跟踪 器 。 最 终 ，PostgreSQL 
9.6 让 这 一 愿望 成 真 ， 它 引入 了 一 个 新 的 系统 视图 。 它 可 以 这 样 使 用 : 


postgres=# SELECT * FROM pg stat progress_ Vacuum ; 


[ RECORD 1 ] 后 
pid | 29546 
datid 1 67535 
datname | test 
relid | 16402 
phase | scanning heap 
heap blks total | 6827 
heap blks scanned | 77 
heap blks vacuumed | 0 
index vacuum count | 0 
max_dead tuples | 154 
num dead tuples 1 0 


PostgreSQL 将 会 提供 有 关 正 在 进行 的 vacuum 进程 的 详细 信息 ， 这 样 人 们 就 可 以 跟踪 
-重要 操作 的 进度 。 


4， 提 升 vacuum 速度 


PostgreSQL 9.6 并 非 只 为 用 户 提供 了 更 深入 的 视角 来 观察 vacuum 当前 正在 干什么 ， 
它 还 从 总 体 上 提升 了 该 处 理 的 速度 。 从 PostgreSQL 9.6 开始 ，PostgreSQL 将 跟踪 所 有 已 
冻结 页 面 并 且 避 免 清 理 这 类 页 面 。 

近乎 于 只 读 的 表 将 大 大 受益 于 这 个 改变 ， 因 为 清理 的 开销 会 被 急剧 降低 。 

1.1.2 ”探究 新 的 SQL 和 开发 者 相关 的 功能 


PostgreSQL 最 有 前 途 的 新 特性 之 一 是 执行 短语 搜索 的 能 力 。 直 到 9.5 都 只 能 搜索 词 ， 
短语 的 搜索 很 难 做 。9.6 漂亮 地 解除 了 这 一 限制 。 下 面 是 短语 搜索 的 例子 : 


test=# SELECT phraseto tsquery('Under pressure') @@ 


这 





to tsvector('Something was under some sort of pressure'); 


?column? 
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(1 row) 


test=# SELECT phraseto tsquery('Under pressure') @@ 
to tsvector('Under pressure by David Bowie hit number 1 again'); 


?column? 


(1 row) 


第 一 个 查询 返回 假 ， 因 为 我 们 要 查找 的 词 没有 按照 想 要 的 顺序 出 现 。 在 第 二 个 查询 
中 会 返回 真 ， 因 为 确实 有 一 个 正确 的 匹配 。 

不 过 ， 这 一 特性 还 不 止 如 此 : 在 9.6 中 可 以 检查 词 是 否 以 特定 的 顺序 出 现 。 在 下 面 的 
例子 中 ， 我 们 想 要 一 个 词 位 于 united 和 nations 之 间 : 


test=# SELECT tsquery('united <2> nations') @@ 
to tsvector('are we really united, happy nations?'); 


?column? 


(1 row) 


test=# SELECT tsquery('united <2> nations') @@ 
to tsvector('are we really at united nations?'); 


?column? 
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(1 row) 
第 二 个 查询 返回 假 ， 因 为 在 united 和 nations 之 间 没 有 词 。 
1.1.3 使 用 新 的 备份 和 复制 功能 

PostgreSQL 9.6 也 在 备份 和 恢复 领域 做 出 了 改进 。 

1. 合理 组 织 wal_level 和 监控 


wal_level 设置 总 是 让 很 多 人 难以 理解 。 很 多 人 都 挣扎 于 archive 和 hot_standby 设置 之 
间 的 区 别 。 为 了 一 并 消除 这 种 困惑 ， 两 种 设置 都 被 替换 成 了 更 容易 理解 的 replica 设置 ， 
其 效果 和 hot_standby 相同 。 

除 此 之 外 ， 对 于 复制 设置 的 监控 也 被 简化 。 在 9.6 以 前 ， 只 有 一 个 pg_stat_replication 
视图 ， 只 能 在 主 服 务 器 上 调用 它 来 监督 流向 从 机 的 数据 。 现 在 也 可 以 用 pg_stat wal_ 
receiver 功能 在 从 机 上 监控 数据 流 。 它 基本 上 就 是 pg_stat_replication 功能 在 从 机 端的 一 个 
镜像 ， 也 可 以 用 来 判断 复制 的 状态 。 


2， 使 用 多 个 同步 后 备 服务 器 


PostgreSQL 早 就 可 以 执行 同步 复制 了 。 从 9.6 开始 ， 在 PostgreSQL 中 可 以 有 不 止 一 
个 同步 服务 器 。 之 前 ， 只 有 一 个 服务 器 需要 认可 提交 。 现 在 可 以 有 一 群 服务 器 ， 它 们 都 
必须 确认 提交 。 如 果 用 户 想 要 在 多 节点 错误 的 情况 下 提升 可 靠 性 ， 这 一 特性 尤其 重要 。 
使 用 这 一 新 特性 的 语法 很 简单 : 


synchronous_standby names = "3 (serverl, server2, server3, server4) 


不 过 ，PostgreSQL 9.6 中 的 同步 复制 还 不 止 如 此 。 之 前 ，PostgreSQL 保证 
(synchronous_commit = on) 事务 日 志 已 经 到 达 从 机 。 不 过 ， 这 并 不 意味 着 数据 就 真正 可 
见 。 考 虑 一 个 例子 : 某 人 对 主 服 务 器 增加 了 一 个 用 户 ， 马 上 连接 到 从 机 检查 该 用 户 。 虽 
然 相 应 的 事务 日 志 被 保证 已 经 到 了 从 机 上 ， 但 是 不 一 定 能 保证 该 日 志 中 的 数据 已 经 对 最 
终 用 户 可 见 ( 由 于 复制 冲突 等 原因 )。 通 过 设置 synchronous_commit = 'remote apply'， 现 
在 可 以 在 主 服 务 器 的 提交 之 后 直接 查询 从 机 ， 而 不 需要 担心 数据 可 能 还 不 可 见 的 问题 。 
remote_apply 值 会 导致 系统 比 使 用 on 值 更 慢 ， 但 是 它 可 用 来 编写 更 加 高 级 的 应 用 。 


1.1.4 理解 性 能 相关 的 特性 
就 像 PostereSQL 的 历次 版 本 发 行 一 样 ，9.6 中 也 有 很 多 性 能 改进 ， 它 们 都 可 以 帮助 应 
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提高 速度 。 在 本 节 中 ， 笔 者 想 着 重 于 最 重要 且 最 强大 的 改进 。 当 然 ， 还 有 很 多 小 的 改 
E 没 法 列举 在 这 里 。 


1， 改 进 关系 扩展 


很 多 年 以 来 ，PostgreSQL 都 是 逐 块 地 扩展 表 (或 者 索引 )。 在 只 有 一 个 写 入 进程 的 情 
况 下 ， 这 还 挺 不 错 。 但 是 ， 在 高 并 发 写 的 情况 下 ， 一 次 写 一 块 就 导致 竞争 且 性 能 不 佳 。 
从 9.6 开始，PostgreSQL 开始 以 一 次 多 块 的 方式 扩展 表 。 一 次 增加 的 块 数 是 正在 等 待 的 进 
程 数量 的 20 倍 。 


2， 检 查 点 排序 和 内 核 交互 


当 PostgreSQL 为 了 检查 点 把 更 改写 入 到 磁盘 时 ， 现 在 它 会 以 一 种 方式 来 确保 这 些 写 
入 比 以 往 更 加 有 顺序 。 其 根本 思路 就 是 在 把 块 写 出 之 前 先 对 它们 排序 。 在 这 种 方式 下 ， 
随机 写 将 被 大 幅度 抑制 ， 这 就 会 在 大 部 分 硬件 上 得 到 更 高 的 吞吐 量 。 

排序 的 检查 点 并 不 是 9.6 中 唯一 的 扩展 性 工作 ， 还 有 一 些 新 的 内 核 回 写 配置 选项 : 这 
有 什么 意义 ? 在 大 缓存 的 情况 下 ， 可 能 需要 相当 长 的 一 段 时 间 将 所 有 的 更 改写 出 。 这 对 
有 具 有数 百 吉 字 节 内 存 的 系统 来 说 尤其 令 人 不 快 ， 因 为 这 样 会 发 生 相 当 剧 烈 的 IO 风暴 。 当 
然 ，Linux 操作 系统 层 行为 可 以 使 用 /proc/sys/vnydirty_background_ratio 命令 更 改 。 但 是 ， 
只 有 届 指 可 数 的 专家 和 系统 管理 员 真正 知道 怎么 做 以 及 为 什么 这 么 做 。 现 在 可 以 使 用 
checkpoint_flush_after、bgwriter_flush_after 和 backend_flush_after 功能 控制 刷 写 行为 ， 通 
常 的 规则 是 尽早 进行 刷 写 。 作 为 一 种 新 特性 ， 人 们 还 在 积累 有 关 如 何 更 有 效 使 用 这 些 设 
置 的 经 验 。 


3. 使 用 更 多 先进 的 外 部 数据 包装 器 


外 部 数据 包装 器 已 经 存在 了 很 多 年 。 从 PostgreSQL 9.6 开始 ， 优 化 器 将 会 以 更 加 高 效 
的 方式 使 用 外 部 表 。 其 中 包括 连接 下 推 〈 连 接 现在 可 以 在 远程 执行 ) 以 及 排序 下 推 〈 排 序 
现在 也 能 在 远程 执行 )。 正 因为 更 快 的 远程 操作 ， 现 在 在 一 个 集群 内 分 布 数据 会 更 加 高 效 。 


4. 引入 并 行 查询 


传统 上 ， 一 个 查询 必须 运行 在 一 个 CPU 上 。 虽 然 在 OLTP 环境 下 这 种 模式 还 过 得 
去 ， 但 对 分 析 型 应 用 来 说 就 有 问题 ， 它 们 会 受 限 于 单 核 的 速度 。PostgreSQL 9.6 引入 了 并 
行 查询 。 当 然 ， 实 现 并 行 查询 很 困难 ， 因 此 所 需 的 一 些 基础 设施 也 已 经 开发 了 多 年 。 现 
在 ， 所 有 这 些 基 础 设施 已 经 可 以 为 最 终 用 户 提供 并 行 的 顺序 扫描 。 其 思想 是 在 顺序 扫描 
时 ， 让 很 多 CPU 工作 在 复杂 的 WHERE 条 件 上 。 版 本 9.6 还 允许 并 行 聚集 和 并 行 连接 。 
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当然 ， 在 这 方面 还 有 很 多 工作 需要 做 ， 但 是 我 们 已 经 看 到 了 一 次 大 的 飞跃 。 
要 控制 并 行 度 ， 有 两 个 基本 设置 ; 
test=# SHOW max worker processes; 


max worker processes 


test=# SHOW max parallel workers per gather; 
max parallel workers per gather 


(1 row) 


第 一 个 限制 可 用 工作 者 进程 的 总 体 数 量 。 第 二 个 控制 每 一 个 收集 节点 允许 使 用 的 工 
作者 数量 。 
在 执行 计划 中 用 户 将 看 到 收集 节点 这 种 新 事物 。 它 负责 统一 来 自 并 行 子 进 
的 程 的 结果 。 除 了 这 些 基 础 设置 之 外 ， 还 有 一 些 新 的 优化 器 参数 可 以 用 来 调整 并 
行 查 询 的 代价 。 


5. 增加 snapshot too old 


用 过 Oracle 的 人 应 该 都 见 过 下 面 的 错误 消息 : snapshot too old。 在 Oracle 中 ， 这 种 消 
息 表 示 一 个 事务 已 经 持续 太 久 ， 因 此 它 必 须 被 中 断 。 在 PostgreSQL 中 ， 事 务 几乎 可 以 无 
限期 运行 。 不 过 ， 长 事务 仍然 可 能 成 为 问题 ， 因 此 9.6 中 增加 了 snapshot too old 的 新 特 
性 ， 它 允许 一 定时 间 之 后 中 止 事务 。 

这 个 特性 的 思想 是 防止 表 膨 胀 并 且 让 最 终 用 户 认 识 到 他 们 可 能 做 了 傻 事 。 





12 总 结 
PostgreSQL 9.6 和 10.0 增加 了 很 多 功能 ， 它 们 允许 人 们 运行 更 加 专业 的 应 用 ， 并 且 能 
运行 得 更 快 、 更 高 效 。 至 于 PostgreSQL 10.0， 准 确 的 新 特性 还 没有 被 完全 定义 出 来 ， 不 
过 本 章 中 已 经 介绍 了 一 些 已 知 的 内 容 。 
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锁定 在 任何 一 种 数据 库 中 都 是 一 个 重要 的 主题 。 仅 仅 理解 它 如 何 帮 助 写 出 更 正确 或 
者 更 好 的 应 用 程序 是 不 够 的 ， 更 重要 的 是 从 性 能 的 角度 来 理解 它 。 如 果 没 有 正确 地 处 理 
锁 ， 用 户 的 应 用 程序 可 能 不 止 是 速度 慢 ， 它 还 可 能 出 现 错误 并 且 做 出 愚蠢 的 行为 。 在 笔 
者 看 来 ， 锁 定 是 性 能 的 关键 ， 对 它 有 一 个 好 的 概述 无 疑 会 有 帮助 。 因 此 ， 理 解锁 定 和 事 
务 对 于 管理 员 和 开发 者 同样 重要 。 

在 本 章 中 ， 读 者 将 学 到 : 

@ 基本 锁定 。 

@ 事务 和 事务 隔离 。 

@ 死 锁 。 

@ 锁定 和 外 键 。 
@ 显 式 和 隐 式 锁定 。 
党 
在 





咨询 锁 。 
本 章 的 最 后 ， 读 者 将 学 会 以 最 有 效 的 方式 理解 和 利用 PostgreSQL 的 事务 。 


2.1 使 用 PostgreSQL 事务 


PostgreSQL 提供 了 一 种 非常 先进 的 事务 机 制 ， 它 为 开发 者 和 管理 员 提 供 了 无 数 的 特 
性 。 在 本 节 中 ， 将 先 看 看 基本 的 概念 。 

要 知道 的 第 一 个 要 点 是 : 在 PostgreSQL 中 ， 每 一 个 操作 都 是 一 个 事务 。 如 果 用 户 向 
服务 器 发 送 一 个 简单 查询 ， 它 就 已 经 是 一 个 事务 。 这 里 有 一 个 例子 : 


test=# SELECT now(), now(); 


2016-08-30 12:03:27.84596+02 | 2016-08-30 12:03:27.84596+02 
(1 row) 
在 这 种 情况 下 ，SELECT 语句 将 是 一 个 单独 的 事务 。 如 果 再 次 执行 同一 个 语句 ， 将 返 
回 一 个 不 同 的 时 间 戳 。 
记 住 now 函数 将 会 返回 该 事务 的 时 间 。 因 此 ，SELECT 语句 总 是 返回 两 个 
相同 的 时 间 戳 。 
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如 果 要 让 多 个 语句 作为 同一 个 事务 的 一 部 分 ， 就 必须 使 用 BEGIN 子 句 : 


test=# \h BEGIN 

Command: BEGIN 

Description: start a transaction block 

Syntax: 

BEGIN [ WORK | TRANSACTION ] [ transaction mode [, ...] ] 


where transaction mode is one of: 


ISOLATION LEVEL { SERIALIZABLE | REPEATABLE READ 
| READ COMMITTED | READ UNCOMMITTED } 

READ WRITE | READ ONLY 

[ NOT ] DEFERRABLE 


BEGIN 子 句 将 确保 多 个 命令 被 包装 到 一 个 事务 中 。 下 面 的 例子 展示 了 它 的 作用 : 
test=# BEGIN; 


BEGIN 
test=# SELECT now(); 


2016=08530 12:13:54.839277+02 
(1 row) 
test=# SELECT now(); 








2016-08-30 12:13:54.839277+02 








(1 row) 

test=# COMMIT; 

COMMIT 

这 里 的 重点 是 两 个 时 间 戳 将 是 完全 一 样 的 。 正 如 之 前 提 到 的 ， 我 们 这 里 所 说 的 是 事 
务 的 时 间 。 


要 结束 事务 ， 可 以 使 用 COMMIT: 


test=# h COMMIT 

Command: COMMIT 

Description: commit the current transaction 
Syntax: 

COMMIT [ WORK | TRANSACTION ] 


这 里 用 到 了 几 个 语法 元 素 ， 用 户 可 以 用 COMMIT、COMMIT WORK 或 者 COMMIT 
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TRANSACTION。 所 有 这 些 选 项 都 具有 相同 的 含义 。 如 果 这 还 不 够 ， 还 有 更 多 的 选择 : 


test=# h END 

Command: END 

Description: commit the current transaction 
Syntax: 

END [ WORK | TRANSACTION ] 


END 子 句 和 COMMIT 子 句 相同 。 

ROLLBACK 是 和 COMMIT 对 应 的 命令 ， 但 它 并 不 是 成 功 地 结束 一 个 事务 ， 它 仅 会 
停止 事务 而 不 把 事务 中 的 部 分 对 其 他 事务 可 见 

test=# h ROLLBRACK 


Command: ROLLBACK 
Description: abort the current transaction 








Syntax: 
ROLLBACK [ WORK | TRANSACTION ] 


有 些 应 用 会 使 用 ABORT 来 奉 代 ROLLBACK， 其 含义 完全 相同 。 
2.1.1 在 事务 内 处 理 错误 


事务 并 不 总 是 从 头 到 尾 都 正确 。 不 过 ， 在 PostgreSQL 中 ， 只 有 没有 错误 的 事务 才能 
被 提交 。 这 里 可 以 看 到 提交 出 错 的 事务 时 会 发 生 什 么 : 

test=# BEGIN; 

BEGIN 


test=# SELECT 1; 
?column? 








(1 row) 


test=# SELECT 1 / 0; 

ERROR: division by zero 

test=# SELECT 1; 

ERROR: current transaction is aborted, commands ignored until end of 
transaction block 

test=# COMMIT; 

ROLLBACK 
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ei 在 任何 正确 的 数据 库 中 ， 像 这 样 的 一 条 指令 将 立刻 出 现 错误 并 且 让 该 语句 
失败 。 


重点 要 指出 的 是 ， 和 MySQL 不 一 样 ，PostgreSQL 将 会 出 错 ， 而 前 者 看 起 来 没有 算术 
错误 结果 的 问题 。 

在 一 个 错误 出 现 后 ， 即 便 后 面 的 指令 在 语义 和 语法 上 都 是 正确 的 ， 也 将 不 会 再 有 语 
名 被 接受 。 这 种 情况 下 ， 仍 然 可 以 发 出 一 个 COMMIT。 不 过 ，PostgreSQL 将 回 滚 该 事 
务 ， 因 为 在 这 种 状况 下 能 做 的 事情 也 就 只 有 回 滚 了 。 


2.1.2 ”使 用 保存 点 


在 专业 应 用 中 ， 很 难 写 出 长 度 合 理 的 事务 而 且 在 运行 中 永 不 出 错 。 为 了 解决 这 一 问 
题 ， 用 户 可 以 利用 所 谓 的 SAVEPOINT。 顾 名 思 义 ， 它 是 事务 中 的 一 个 安全 位 置 ， 在 出 现 
背 误 事件 时 应 用 可 以 返回 到 这 些 位 置 。 这 里 有 一 个 例子 

test=# BEGIN; 

BEGIN 


test=# SELECT 1; 
?column? 


























(1 row) 


test=# SAVEPOINT a; 
SAVEPOINT 
test=# SELECT 2 / 0; 
ERROR: division by zero 
test=# ROLLBACK TO SAVEPOINT a; 
ROLLBACK 
test=# SELECT 3; 
?column? 


(1 row) 


test=# COMMIT; 
COMMIT 


在 第 一 个 SELECT 子 句 后 面 ， 笔 者 决定 创建 一 个 SAVEPOINT 来 确保 应 用 总 是 可 以 
在 事务 内 返回 到 这 一 点 。 如 你 所 见 ，SAVEPOINT 有 一 个 名 字 ， 在 后 面 会 用 这 个 名 字 来 引 
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用 它 。 
在 返回 到 a 之 后 ， 事 务 可 以 正常 地 继续 下 去 。 代 码 已 经 跳 回 到 错误 发 生 之 前 ， 所 以 
所 有 事情 都 是 正常 的 。 








一 个 事务 内 部 的 保存 点 数量 没有 限制 。 我 们 已 经 见 过 有 客户 在 一 个 单一 操作 中 使 用 
超过 250000 个 保存 点 。PostgreSQL 可 以 轻松 地 处 理 这 样 的 情况 。 

如 果 用 户 想 在 一 个 事务 内 移 除 一 个 保存 点 ， 有 一 个 命令 RELEASE SAVEPOINT 
可 用 : 

test=# h RELEASE SAVEPOINT 

Command: RELEASE SAVEPOINT 

Description: destroy a previously defined savepoint 


Syntax: 
RELEASE [ SAVEPOINT ] savepoint name 


很 多 人 会 问 ， 如 果 在 一 个 事务 结束 之 后 尝试 到 达 一 个 保存 点 会 发 生 什 么 ? 答案 是 ， 
事务 结束 时 保存 点 的 寿命 也 随 之 终止 。 换 句 话说 ， 在 事务 已 经 被 结束 之 后 无 法 返回 到 一 
个 特定 的 点 。 


2.1.3 事务 性 DDL 


很 不 幸 ，PostgreSQL 有 一 些 很 好 的 特性 在 很 多 商业 数据 库 系统 中 并 不 存在 。 在 
PostgreSQL 中 ， 可 以 在 一 个 事务 块 中 运行 DDL (改变 数据 结构 的 命令 )。 在 一 个 典型 的 商 
业 系统 中 ， 在 当前 事务 中 的 DDL 将 会 被 隐 式 地 提交 ， 但 在 PostgreSQL 中 不 是 这 样 。 除 去 少 
量 例外 (DROP DATABASE、CREATE TABLESPACE/DROP TABLESPACE 等 )，PostgreSQL 
中 所 有 的 DDL 都 是 事务 性 的 ， 这 会 给 最 终 用 户 带 来 巨大 的 好 处 和 真正 的 实惠 。 

这 里 有 一 个 例子 : 


test=# d 
No relations found. 
test=# BEGIN; 
BEGIN 
test=# CREATE TABLE t test (id int); 
CREATE TABLE 
test=# ALTER TABLE t test ALTER COLUMN id TYPE int8; 
ALTER TABLE 
test=# dt test 
Tableol public te teat 
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id LU pigint | 


test=# ROLLBACK; 

ROLLBACK 

test=# d t test 

Did not find any relation named "t test". 

在 这 个 例子 中 创建 并 修改 了 一 个 表 ， 然 后 整个 事务 被 立刻 中 止 。 如 你 所 见 ， 其 中 没 
有 隐 式 的 COMMIT 或 者 任何 其 他 奇怪 的 行为 ，PostgreSQL 也 能 按照 我 们 的 期 望 工作 。 

如 果 用 户 想 要 部 署 软件 ， 事 务 性 DDL 特别 重要 。 想 象 运行 一 个 CMS 的 场景 。 如 果 
发 布 了 一 个 新 的 版 本 ， 用 户 将 会 想 要 升级 。 单 独 运行 旧版 本 或 者 新 版 本 可 能 都 是 可 以 
的 ， 但 是 用 户 不 希望 得 到 新 旧版 本 的 混合 体 。 因 此 ， 将 升级 放 在 一 个 单一 事务 内 无 疑 会 
大 有 益处 ， 因 为 这 会 使 升级 变 成 一 个 原子 操作 。 

6 psql 允许 用 户 使 用 i 指令 包括 文件 。 它 允许 用 户 开始 一 个 事务 、 载 入 一 些 
文件 并 且 在 一 个 单一 事务 中 执行 它们 。 








2.2 理解 基本 的 锁定 


在 本 节 中 ， 读 者 将 学 到 基本 的 锁定 机 制 。 本 节 的 目标 是 让 读者 理解 锁 通 常 是 如 何 工 
作 的 以 及 如 何 让 简单 应 用 正确 运行 。 作 为 例子 ， 可 以 创建 一 个 简单 表 。 为 了 便于 展示 ， 
笔者 将 增加 一 行 到 该 表 中 : 

test=# CREATE TABLE t test (id int); 

CREATE TABLE 


test=# INSERT INTO t test VALUES (1); 
INSERT 0 1 


重点 是 表 可 以 被 并 发 读 取 。 很 多 同时 读 取 相 同 数据 的 用 户 不 会 彼此 阻塞 。 这 人 允许 
PostgreSQL 处 理 上 千 个 用 户 而 不 出 问题 。 








人 多 个 用 户 可 以 同时 读 取 同 样 的 数据 而 不 彼此 阻塞 。 


现在 的 问题 是 ， 如 果 读 写 同 时 产生 会 发 生 什么 ? 这 里 有 一 个 例子 ， 如 表 2-1 所 示 。 
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表 2-1 


事务 1 事务 2 


BEGIN: 





BEGIN: 

UPDATE t test SET id =id + 1 RETURNING *: 
用 户 将 看 到 1 SELECT* FROM t test: 
用 户 将 看 到 1 
COMMIT: 








COMMIT: 
两 个 事务 被 打开 。 第 一 个 将 更 改 一 行 。 不 过 这 不 会 有 问题 ， 因 为 第 二 个 事务 可 以 继 
续 。 它 将 返回 旧 的 行 ， 也 就 是 在 UPDATE 之 前 的 行 。 这 种 行为 被 称 为 多 版 本 并 发 控制 
(MVCC )。 
注意 事务 将 只 能 看 到 已 经 被 写 事务 提交 的 数据 。 一 个 事务 不 能 观察 到 由 一 个 活跃 连 
接 造 成 的 改变 。 























9 一 个 事务 只 能 看 到 已 经 被 提交 的 更 改 


还 有 第 二 个 重要 的 方面 : (截至 2017 年 ) 很 多 商业 或 者 开源 数据 库 仍 然 不 能 处 理 并 
发 读 写 。 在 PostgreSQL 中 绝对 没有 这 样 的 问题 ， 读 写 是 可 以 共存 的 ， 写 事务 不 会 阻塞 读 
事务 。 在 数据 被 提交 之 后 ， 该 表 将 会 包含 2。 

如 果 两 个 用 户 同时 修改 同一 数据 会 发 生 什 么 ? 这 里 有 个 例子 ， 如 表 2-2 所 示 。 

表 2-2 





事务 1 事务 2 





BEGIN; 
UPDATE t test SET 1d=1d + 1 RETURNING *; 
它 将 返回 3 


BEGIN; 





UPDATE t test SET 1d=1d+ 1 RETURNING *; 
它 将 等 待 事务 1 
它 将 等 待 事务 1 
它 现在 将 重新 读 取 ， 并 且 找 到 3、 设 置 值 ， 然 后 
返回 4 
COMMIT:; 
假设 用 户 想 要 统计 一 个 网 站 的 点 击 数 。 如 果 运 行 刚 才 概 述 的 代码 ， 不 会 有 点 击 会 被 
漏 掉 ， 因 为 PostgreSQL 保证 一 个 UPDATE 会 在 其 他 更 新 之 后 被 运行 。 








COMMIT; 
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PostgreSQL 只 会 锁定 被 UPDATE 影响 的 行 。 因 此 如 果 有 1000 行 ， 理论 上 
用 户 可 以 在 同一 个 表 上 运行 1000 个 并 发 更 改 。 


还 值得 提 到 的 一 点 是 ， 用 户 总 是 可 以 运行 并 发 读 。 我 们 的 两 个 写 操作 将 不 会 阻塞 读 。 

@ 避免 典型 错误 和 显 式 锁定 

在 笔者 作为 一 个 职业 PostgreSQL 顾问 (http://postgresql-support.de/) 的 生涯 中 ， 已 经 
见 过 了 不 少 被 一 次 又 一 次 重复 的 错误 。 如 果 生 命中 有 什么 是 永恒 的 ， 那 么 这 些 典型 错误 
绝对 是 一 些 从 不 改变 的 。 

下 面 是 笔者 的 最 爱 ， 如 表 2-3 所 示 。 





表 2-3 
事务 1 事务 2 
BEGIN; BEGIN: 
SELECT max(id) FROM product: SELECT max(id) FROM product: 
用 户 将 看 到 17 用 户 将 看 到 17 
用 户 将 决定 用 18 用 户 将 决定 用 18 
INSERT INTO product … VALUES INSERT INTO product … VALUES 
i L 
COMMIT': COMMIT: 
在 这 一 情况 中 ， 将 会 有 一 次 重复 键 违规 或 者 两 个 完全 一 样 的 项 。 这 个 问题 的 两 个 变 


种 都 不 是 我 们 想 要 的 。 
修正 这 个 问题 的 一 种 方式 是 使 用 显 式 表 锁定 : 
test=# h LOCK 
Command : LOCK 
Description: lock a table 
Syntax: 
LOCK [ TABLE ] [ ONLY ] name [ * ] [, ...] [IN lockmode MODE ] [ NOWAIT ] 


where lockmode is one of: 


ACCESS SHARE | ROW SHARE | ROW EXCLUSIVE | 
SHARE UPDATE EXCLUSIVE| SHARE | 
SHARE ROW EXCLUSIVE | EXCLUSIVE | ACCESS EXCLUSIVE 


如 你 所 见 ，PostgreSQL 为 锁定 一 个 表 提 供 了 8 种 类 型 的 锁 。 在 PostgreSQL 中 ， 一 个 
锁 可 以 轻 如 ACCESS SHARE 锁 或 者 重 如 ACCESS EXCLUSIVE 锁 。 下 面 展 示 了 这 些 锁 会 
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ACCESS SHARE: 这 种 类 型 的 锁 由 读 操作 获取 ， 它 只 与 ACCESS EXCLUSIVE 
冲突 ， 后 者 会 由 DROP TABLE 之 类 的 操作 获取 。 事 实 上 ， 这 意味 着 如 果 一 个 表 
就 要 被 删除 ， 则 不 能 开始 一 个 SELECT。 这 也 暗示 着 DROP TABLE 不 得 不 等 待 
直到 一 个 读 取 事务 完成 。 

ROW SHARE: PostereSQL 会 在 SELECT FOR UPDATE/SELECT FOR SHARE 
的 情况 下 取得 这 种 锁 。 它 与 EXCLUSIVE 以 及 ACCESS EXCLUSIVE 冲突 。 
ROW EXCLUSIVE: 这 种 锁 由 INSERT、UPDATE 和 DELETE 取得 。 它 与 
SHARE、SHARE ROW EXCLUSIVE、EXCLUSIVE 还 有 ACCESS EXCLUSIVE 
冲突 。 

SHARE UPDATE EXLUSIVE: 这 种 锁 由 CREATE INDEX CONCURRENTLY、 
ANALYZE、ALTER TABLE、VALIDATE 和 其 他 和 VACUUM ( 非 VACUUM 
FULL) 一 样 的 ALTER TABLE 形式 取得 。 它 与 SHARE UPDATE EXCLUSIVE、 
SHARE、SHARE ROW EXCLUSIVE、EXCLUSIVE 以 及 ACCESS EXCLUSIVE 
锁 模 式 冲 突 。 

SHARE: 当 一 个 索引 被 创建 时 ， 将 会 设置 SHARE 锁 。 它 与 ROW EXCLUSIVE、 
SHARE UPDATE EXCLUSIVE、SHARE ROW EXCLUSIVE、EXCLUSIVE 和 
ACCESS EXCLUSIVE 冲突 。 

SHARE ROW EXCLUSIVE: 这 种 锁 由 CREATE TRIGGER 和 某 些 形式 的 
ALTER TABLE 设置 ， 并 且 与 除了 ACCESS SHARE 之 外 的 所 有 模式 都 冲突 。 
EXCLUSIVE: 这 种 类 型 的 锁 是 目前 为 止 最 严格 的 一 种 。 它 保护 操作 不 受 读 和 写 
的 影响 。 如 果 一 个 事务 取得 了 这 种 锁 ， 任 何其 他 人 都 不 能 读 取 或 者 写 入 受 影响 
的 表 。 














有 了 这 样 的 PostgreSQL 锁定 结构 ， 对 于 之 前 的 最 大 值 问题 的 一 种 解决 方案 可 以 是 : 


BEGIN; 

LOCK TABLE product IN ACCESS EXCLUSIVE MODE; 

INSERT INTO product SELECT max(id) + 1, ... FROM product; 
COMMIT; 


要 记 住 对 于 此 类 操作 这 是 一 种 很 不 好 的 方式 ， 因 为 在 操作 期 间 没有 任何 其 他 人 可 以 
读 取 或 者 写 入 该 表 。 因 此 ， 应 该 不 惜 一 切 代 价 避 免 ACCESS EXCLUSIVE。 


考虑 可 蔡 换 的 解决 方案 


不 过 ， 还 是 有 一 种 替代 解决 方案 可 以 用 于 该 问题 。 考 虑 下 面 的 例子 : 税务 所 要 求 你 
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编写 一 个 生成 发 票 编 号 的 应 用 。 税 务 所 可 能 要 求 你 创建 的 发 票 编 号 没有 间隔 也 没有 习 
复 。 你 应 该 怎么 做 呢 ? 当然 ， 一 种 方案 会 是 表 锁 。 但 是 你 实际 上 可 以 做 得 更 好 。 下 面 看 
看 笔者 会 怎么 做 : 


test=# CREATE TABLE t invoice (id int PRIMARY KEY); 

CREATE TABLE 

test=# CREATE TABLE t watermark (id int); 

CREATE TABLE 

test=# INSERT INTO t watermark VALUES (0); 

INSERT 0 1 

test=# WITH x AS (UPDATE t watermark SET id = id + 1 RETURNING *) 
INSERT INTO t invoice 
SELECT * FROM x RETURNING *; 


是 





id 


1 

(1 row) 

在 这 种 情况 下 ， 笔 者 引入 了 一 个 名 为 t_watermark 的 表 ， 它 只 包含 一 行 。WITH 部 分 
被 首先 执行 。 该 行将 被 锁定 并 且 增加 ， 得 到 的 新 值 将 被 返回 。 一 个 时 间 点 只 有 一 个 人 能 
这 样 做 。 接 着 ，CTE 返回 的 值 被 用 在 发 票 表 中 ， 它 被 保证 是 唯一 的 。 其 中 最 美妙 的 事情 
是 只 在 watermark 表 上 有 一 个 简单 的 行 锁 ， 在 发 票 表 上 的 读 取 操 作 将 不 会 被 阻塞 。 总 的 来 
说 ， 这 种 方法 更 具有 可 扩展 性 。 





2.3 使 用 FOR SHARE 和 FOR UPDATE 


有 时 ， 应 用 会 从 数据 库 中 选择 一 些 数据 ， 然 后 对 它们 做 一 些 处 理 并 且 最 终 将 一 些 被 
更 改 的 数据 存 回 到 数据 库 ， 这 是 SELECT FOR UPDATE 的 一 种 典型 用 例 。 

下 面 是 一 个 例子 : 

BEGIN; 


SELECT * FROM invoice WHERE processed = false; 
** application magic will happen here ** 





UPDATE invoice SET processed = true ... 
COMMIT; 


这 里 的 问题 是 两 个 人 可 能 选择 相同 的 未 处 理 数据 。 那 么 对 于 那些 已 处 理 行 的 更 改 将 
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会 被 覆盖 。 简 而 言 之， 将 会 发 生 一 种 竞争 的 情况 。 


改 。 


为 了 解决 这 一 问题 ， 开 发 者 可 以 使 用 SELECT FOR UPDATE。 例 如 : 


BEGIN; 

SELECT * FROM invoice WHERE processed = false FOR UPDATE; 
** application magic will happen here ** 

UPDATE invoice SET processed = true ... 

COMMIT; 


SELECT FOR UPDATE 将 会 像 UPDATE 那样 锁 住 行 ， 这 意味 着 不 会 发 生 并 发 的 更 
所 有 的 锁 会 照常 在 提交 时 被 释放 。 如 果 一 个 SELECT FOR UPDATE 在 等 待 其 他 某 个 


SELECT FOR UPDATE， 屠 前 者 就 不 得 不 等 到 后 者 结束 “COMMIT 或 者 ROLLBACK )。 
如 果 被 等 待 的 事务 不 想 结束 ， 那 么 等 待 着 的 事务 可 能 会 永远 等 待 。 


为 了 避免 这 种 情况 ， 可 以 使 用 SELECT FOR UPDATE NOWAIT， 如 表 2-4 所 示 。 
可 以 这 样 做 : 


表 2-4 
事务 1 事务 2 
BEGIN; BEGIN:; 
SELECT ... FROM tab WHERE ... 
FOR UPDATE NOWAIT:; 
此 处 理 SELECT ... FROM tab WHERE ... FOR 
UPDATE NOWAIT: 
一 些 处 理 ERROR: could not obtain lock on row 





in relation tab 


如 果 用 户 觉得 NOWAIT 不 够 灵活 ， 可 以 考虑 使 用 lock_timeout， 它 表示 用 户 想 要 人 花 


在 等 待 锁 上 的 时 间 。 可 以 在 会 话 级 别 上 设置 这 个 参数 : 


test=# SET lock timeout TO 5000; 
SET 


在 上 例 中 ， 该 值 被 设 为 5 秒 。 
虽然 SELECT 基本 不 做 锁定 ， 但 SELECT FOR UPDATE 可 能 会 相当 严格 。 想 象 一 下 


下 面 的 业务 处 理 : 我 们 想 填 满 一 架 提供 200 个 座位 的 飞机 ， 很 多 人 想 要 并 发 地 预订 座 


位 。 


在 这 种 情况 下 ， 将 会 发 生 表 2-5 所 示 的 情景 。 
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表 2-5 
事务 1 事务 2 
BEGIN; BEGIN; 
SELECT ... FROM flight LIMIT 1 FOR 
UPDATE:; 
yy SELECT ... FROM flight LIMIT 1 FOR 
等 和 1 输入 
等 待 用 户 输 A 
等 待 用 户 输入 必须 等 待 


这 里 的 问题 在 于 在 一 个 时 间 点 上 只 能 有 一 个 座位 被 预订 。 可 以 用 来 预订 的 座位 实际 
上 有 200 个 ， 但 是 每 一 个 人 都 必须 等 待 第 一 个 人 。 虽 然 第 一 个 座位 已 经 被 阻塞 ， 但 是 即 
便 人 们 并 不 在 乎 最 后 得 到 哪个 座位 ， 也 没有 其 他 人 可 以 预订 其 他 的 座位 。 

SELECT FOR UPDATE SKIP LOCKED 将 会 修复 这 一 问题 。 让 我 们 先 创建 一 些 示 例 
数据 : 

test=# CREATE TABLE t flight AS 


SELECT * FROM generate series(1, 200) RS id; 
SELECT 200 


下 面 是 见证 奇迹 的 时 刻 ， 如 表 2-6 所 示 。 


表 2-6 
事务 1 事务 2 
BEGIN; BEGIN: 
SELECT * FROM t flight LIMIT 2 FOR SELECT * FROM t flight LIMIT 2 FOR 
UPDATE SKIP LOCKED: UPDATE SKIP LOCKED: 
会 返回 1，2 会 返回 3，4 











如 果 每 个 人 都 想 要 取得 两 行 ， 可 以 在 同一 时 间 服 务 100 个 并 发 事务 而 不 需要 担心 阻 
塞 事务 。 


人 要 记 住 ， 等 待 是 最 慢 的 一 种 执行 形式 。 如 果 在 一 个 时 间 点 只 有 一 个 CPU 可 
以 活动 ， 购 买 更 大 的 服务 器 就 没有 意义 








不 过 还 有 更 多 需要 考虑 的 事情 。 在 某 些 情况 下 ，FOR UPDATE 可 能 有 意 想 不 到 的 结 
。 大 部 分 人 并 没有 意识 到 FOR UPDATE 将 会 影响 外 键 这 一 事实 。 让 我 们 假定 有 两 个 
: 一 个 存储 货币 ， 另 一 个 存储 账户 : 


站 外 


CREATE TABLE t currency (id int, name text, PRIMARY KEY (id)); 
INSERT INTO t currency VALUES (1, ‘'EUR'); 
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INSERT INTO t currency VALUES (2, 'USD'); 


CREATE TABLE t account (id int, currency id int REFERENCES t currency (id) 
ON UPDATE CASCADE ON DELETE CASCADE, balance numeric); 

INSERT INTO t account VALUES (1, 1, 100); 

INSERT INTO t account VALUES (2, 1, 200); 


现在 想 要 在 账户 表 上 运行 SELECT FOR UPDATE， 如 表 2-7 所 示 。 








表 2-7 
事务 1 事务 2 
BEGIN; 
SELECT* FROMt account FOR UPDATE: BEGIN: 
等 待 用 户 继续 UPDATE t currency SET id =id * 10; 
等 待 用 户 继续 它 将 等 待 事务 1 


尽管 是 在 账户 表 上 有 SELECT FOR UPDATE， 但 货币 表 上 的 UPDATE 却 将 阻塞 。 这 
样 做 是 有 必要 的 ， 和 否则 就 会 有 机 会 破坏 外 键 约束 。 因 此 ， 在 比较 复杂 的 数据 结构 中 ， 可 
以 很 容易 地 避免 在 最 不 想 出 现 竞争 的 地 方 〈 一 些 非常 重要 的 查阅 表 ) 碰 到 竞争 。 

在 FOR UPDATE 之 上 ,还 有 FOR SHARE、FOR NO KEY UPDATE 以 及 FOR KEY 
SHARE。 下 面 的 列表 描述 了 这 些 模式 究竟 意味 着 什么 。 

@ FOR NO KEY UPDATE: 这 种 模式 很 像 FOR UPDATE。 不 过 ， 这 种 锁 要 更 弱 一 
些 并 且 因此 能 和 SELECT FOR SHARE 共存 。 

@ FOR SHARE: FOR UPDATE 是 一 种 相当 强 的 锁 ， 它 假设 用 户 肯 定 会 去 更 改行 。 
FOR SHARE 与 之 不 同 ， 因 为 可 以 有 多 于 一 个 事务 在 同一 时 刻 都 持 有 FOR 
SHARE 锁 。 

@ FOR KEY SHARE: 这 种 模式 的 行为 类 似 于 FOR SHARE， 不 过 这 种 锁 较 弱 。 它 
将 阻塞 FOR UPDATE 但 不 会 阻塞 FOR NO KEY UPDATE。 

要 理解 这 些 锁 模式 的 含义 ， 最 简单 直观 的 方式 就 是 进行 尝试 并 且 观 察 会 发 生 什 么 。 

改进 锁定 行为 确实 非常 重要 ， 因 为 它 能 大 幅度 地 提升 应 用 的 可 扩展 性 。 


2.4 理解 事务 隔离 级 别 











到 目前 为 止 ， 读 者 已 经 见 到 了 如 何 处 理 锁定 以 及 一 些 基 本 的 并 发 。 在 本 节 中 ， 读 者 
将 学 到 事务 隔离 。 对 笔者 而 言 ， 这 是 现代 软件 开发 中 最 容易 被 忽略 的 主题 之 一 。 只 有 一 
小 部 分 软件 开发 者 真正 意识 到 了 这 个 问题 ， 而 它 又 会 导致 令 人 反感 而 且 难 以 置信 的 
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缺陷 。 
下 面 是 有 关于 此 的 一 个 例子 ， 如 表 2-8 所 示 。 
表 2-8 
事务 1 事务 2 

BEGIN; 

SELECT sum(balance) FROM t account; 

用 户 将 看 到 300 BEGIN; 
INSERT INTO t account (balance) VALUES (100); 
COMMIT: 


SELECT sum(balance) FROM t account; 

用 户 将 看 到 400 

COMMIT': 

不 管 第 二 个 事务 怎样 ， 大 部 分 用 户 实际 上 会 期 望 左边 的 事务 一 直 返 回 300， 但 是 事实 
并 非 如 此 。 默 认 情 况 下 ，PostgreSQL 运行 在 READ COMMITTED 事务 隔离 模式 中 。 这 意 
味 着 事务 中 的 每 个 语句 都 将 得 到 数据 的 一 个 新 快照 ， 它 在 整个 查询 期 间 都 不 变 。 

一 个 SQL 语句 将 在 同一 个 快照 上 进行 操作 并 且 会 忽略 在 它 运行 期 间 并 发 事 
务 所 作 的 更 改 

如 果 用 户 想 避免 这 种 情况 ， 可 以 使 用 TRANSACTION ISOLATION LEVEL 
REPEATABLE READ。 在 这 种 事务 隔离 级 别 中 ， 一 个 事务 将 在 整个 事务 期 间 都 使 用 同一 
个 快照 。 下 面 是 使 用 这 种 隔离 级 别 的 例子 ， 如 表 2-9 所 示 。 


表 2-9 





事务 1 事务 2 
BEGIN TRANSACTION ISOLATION LEVEL 
REPEATABLE READ: 

SELECT sum(balance) FROM t_ account: 


户 将 看 到 300 














BEGIN; 

TINSERT INTO t_account (balance) VALUES (100); 
COMMIT: 

SELECT sum(balance) FROM t_account; 
用 户 将 看 到 400 

















SELECT sum(balance) FROM t_ account: 
用 户 将 看 到 300 
COMMIT: 
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如 上 所 示 ， 第 一 个 事务 将 会 冻结 它 的 数据 快照 ， 并 且 在 整个 事务 期 间 都 为 我 们 提供 
一 致 的 结果 。 如 果 用 户 想 要 运行 报表 ， 这 个 特性 将 会 特别 重要 。 一 份 报表 的 第 一 页 和 最 
后 一 页 应 该 总 是 一 致 的 ， 并 且 都 在 相同 的 数据 上 操作 。 因 此 ， 可 重复 读 是 让 报表 一 致 的 
关键 。 

注意 隔离 相关 的 错误 不 会 总 是 立刻 跳出 来 ， 它 可 能 会 在 一 个 应 用 移 到 生产 环境 后 数 
年 才 被 发 现 。 





人 可 重复 读 并 不 比 读 已 提交 更 昂贵 ， 所 以 不 需要 担心 性 能 上 受到 的 惩罚 。 


@ 考虑 SSI 事务 

在 读 已 提交 和 可 重复 读 之 上 ，PostgreSQL 提供 了 可 序列 化 (简称 SSI) 事务 。 因 此 ， 
PostgreSQL 总 共 支 持 3 种 隔离 级 别 。 注 意 读 未 提交 (在 一 些 商 业 数 据 库 中 还 是 作为 默认 
级 别 ) 不 受 支持 : 如 果 用 户 尝试 开始 一 个 读 未 提交 的 事务 ，PostgreSQL 会 悄 无 声息 地 把 
它 映 射 成 读 已 提交 。 不 过 ， 现 在 让 我 们 还 是 回 到 可 序列 化 。 

可 序列 化 背后 的 思想 很 简单 ， 如 果 在 只 有 一 个 用 户 的 情况 下 一 个 事务 是 正确 工作 
的 ， 在 选择 这 种 隔离 级 别 时 它 也 能 在 并 发 情况 下 工作 。 不 过 ， 用 户 必 须 做 好 准备 : 事务 
可 能 会 失败 〈 设 计 就 是 这 样 ) 并 且 报 错 。 除 此 之 外 ， 还 会 付出 性 能 上 的 代价 。 

如 果 读 者 想 要 了 解 更 多 有 关 这 种 隔离 级 别 的 内 容 ， 可 以 考虑 看 看 https://wikipostgresql. 
org/wiki/Serializable。 








人 只 有 当 用 户 对 数据 库 引 擎 内 部 有 深入 的 了 解 时 才 考 虑 使 用 可 序列 化 。 


2.5 观察 死 锁 和 类 似 的 问题 


死 锁 是 一 个 重要 的 问题 ， 它 可 能 会 发 生 在 每 一 个 笔者 知道 的 数据 库 中 。 大 体 上 ， 如 
果 两 个 事务 不 得 不 相互 等 待 ， 就 将 发 生 一 次 死 锁 。 

在 本 节 中 ， 读 者 将 看 到 怎么 会 发 生死 锁 。 让 我 们 假设 有 一 个 包含 两 行 的 表 : 

CREATE TABLE t deadlock (id int); 

INSERT INTO t deadlock VALUES (1), (2); 


表 2-10 展示 了 会 发 生 什 么 : 
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表 2-10 


BEGIN; 

UPDATE t deadlock SET id = id * 10 WHERE 
id= 1; 

UPDATE t deadlock SET id = id * 10 WHERE 
id=2; 


BEGIN; 





UPDATE t deadlock SET id= id * 10 WHERE id=2; 











等 待 事 务 2 UPDATE t deadlock SET id= id* 10 WHERE id= 1; 
等 待 事务 2 等 待 事 务 1 

1 秒 (deadlock timeout) 以 后 死 锁 会 被 解除 
COMMIT: 


ROLLBACK; 





一 旦 检测 到 死 锁 ， 将 会 显示 下 面 的 错误 消息 : 
ERROR: deadlock detected 


DETAIL: Process 91521 waits for ShareLock on transaction 903; blocked by 
process 77185. 


Process 77185 waits for ShareLock on transaction 905; blocked by process 
91521. 


HINT: See server log for query details. 

CONTEXT: while updating tuple (0,1) in relation "t deadlock" 

PostgreSQL 甚至 会 告诉 我 们 哪 一 行 导致 了 该 冲突 。 在 笔者 的 例子 中 ， 所 有 罪恶 的 根 
源 是 元 组 (0,1)。 这 里 读者 能 看 到 的 是 一 个 ctid， 它 告诉 我 们 一 行 在 表 中 的 物理 位 置 。 在 这 
个 例子 中 ， 它 是 第 一 块 0) 中 的 第 一 行 。 

如 果 这 一 行 对 用 户 的 事务 还 可 见 ， 甚 至 可 以 查询 这 一 行 : 

test=# SELECT ctid, * FROM t deadlock WHERE ctid = '(0, 1)'; 

ctid ll ad 
和 本 


(OR 
(1 row) 


要 记 住 如 果 一 个 行 已 经 被 删除 或 者 修改 ， 这 个 查询 是 不 会 返回 该 行 的 。 

不 过 ， 它 并 非 是 死 锁 导致 事务 失败 的 唯一 情况 。 当 事务 由 于 一 些 原因 没有 被 序列 化 
时 ， 也 可 能 发 生 同 样 的 事情 。 表 2-11 会 展示 这 一 现象 。 为 了 让 这 个 例子 能 够 工作 ， 笔 者 
假定 表 中 仍然 有 两 行 : id=1 和 id=2。 
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表 2-11 
事务 1 
BEGIN ISOLATION LEVEL REPEATABLE READ:; 
SELECT* FROM t_ deadlock:; 
将 返回 两 行 


事务 2 














DELETE FROM t deadlock; 





SELECT * FROM t deadlock': 

将 返回 两 行 

DELETE FROMt deadlock': 

事务 将 会 出 错 

ROLLBACK; -我 们 不 再 能 COMMIT 


在 这 个 例子 中 ， 两 个 并 发 事务 在 运行 。 只 要 事务 1 仅 选 择 数据 ， 一 切 都 不 会 有 问 
题 ， 因 为 PostgreSQL 可 以 轻易 地 保存 静态 数据 的 幻象 。 但 是 如 果 第 二 个 事务 提交 了 一 次 
DELETE 会 发 生 什 么 呢 ? 只 要 事务 1 中 仅 执行 读 ， 则 仍然 不 会 有 问题 。 当 事务 1 尝试 删除 
或 者 修改 数据 时 麻烦 就 开始 了 ， 因 为 这 些 数据 在 这 一 时 刻 实际 上 已 经 死亡 了 。 对 于 
PostgreSQL 来 说 ， 这 里 唯一 的 解决 方案 就 是 报错 : 

test=# DELETE FROM t deadlock; 

ERROR: could not serialize access due to concurrent update 

实际 上 ， 这 意味 着 最 终 用 户 不 得 不 准备 好 处 理 出 错 的 事务 。 如 果 出 了 差错 ， 正 确 编 
写 的 应 用 必须 能 够 进行 重 试 。 

















2.6 利用 咨询 锁 


PostgreSQL 有 一 套 非常 有 效 而 且 复杂 的 事务 机 制 ， 它 能 够 以 非常 细 粒 度 和 高 效 的 方 
式 来 处 理 锁 。 数 年 前 ， 有 人 冒 出 了 使 用 这 套 代码 来 在 应 用 之 间 同 步 的 想法 。 这 样 ， 咨 询 
锁 便 诞生 了 。 

在 使 用 咨询 锁 时 ， 一 定 要 提 及 的 是 它们 不 会 像 普 通 锁 那样 在 COMMIT 后 就 消失 。 因 
此 ， 确 保 以 正确 可 靠 的 方式 完成 解锁 是 非常 重要 的 。 

如 果 用 户 决定 使 用 一 个 咨询 锁 ， 他 /她 实际 锁 住 的 是 一 个 数字 。 所 以 这 与 行 或 者 数据 
无 关 : 它 真 的 就 是 一 个 数字 。 下 面 是 怎么 用 咨询 锁 的 例子 ， 如 表 2-12 所 示 。 
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表 2-12 
会 话 1 会 话 2 

BEGIN: 
SELECT pg _advisory_lock(15); 

SELECT pg advisory lock(15); 
COMMIT': 它 仍然 要 等 待 
SELECT pg advisory unlock(15); 它 还 在 等 待 

锁 被 得 到 





第 一 个 事务 将 锁 住 15。 第 二 个 事务 不 得 不 等 待 ， 直 到 这 个 数字 被 再 次 解锁 。 在 第 一 
个 事务 已 经 提交 后 ， 第 二 个 会 话 还 将 等 待 。 这 是 非常 重要 的 ， 因 为 我 们 不 能 指望 事务 会 
完美 地 结束 并 且 神 奇 地 为 我 们 解决 这 些 事情 。 

如 果 用 户 想 要 解锁 所 有 锁 住 的 数字 ，PostgreSQL 提供 了 pg_advisory_unlock all0 函 数 
来 做 这 件 事 : 

test=# SELECT pg advisory unlock al1() 

pg advisory unlock al1 





(1 row) 


有 时 候 用 户 可 能 想 看 看 是 否 能 得 到 一 个 锁 并 且 在 不 能 得 到 时 报错 。 为 了 实现 这 种 功 
能 ，PostgreSQL 提供 了 几 个 函数 。 如 果 用 户 使 用 df *try*advisory*，PostgreSQL 会 返回 所 
有 可 用 函数 的 列表 。 


2.7 优化 存储 以 及 控制 清理 


事务 是 PostgreSQL 系统 一 个 完整 的 部 分 。 不 过 ， 伴 随 事 务 的 还 有 一 点 小 小 的 代价 。 
正如 本 章 中 已 经 展示 过 的 ， 可 能 会 出 现 为 并 发 用 户 展 现 不 同 数据 的 情况 。 对 于 一 个 查 
询 ， 不 是 每 一 个 人 都 会 得 到 相同 的 返回 数据 。 除 此 之 外 ，DELETE 和 UPDATE 不 能 直接 
履 盖 数据 ， 因 为 那样 ROLLBACK 就 将 无 法 工作 。 如 果 用 户 恰好 处 于 一 次 大 型 DELETE 
操作 的 中 间 ， 他 /她 将 不 能 确定 是 否 能 够 COMMIT。 还 有 ， 当 用 户 执行 DELETE 时 ， 涉 及 
的 数据 仍然 是 可 见 的 ， 甚 至 有 时 在 修改 完成 很 久 以 后 数据 都 是 可 见 的 。 

所 以 ， 这 意味 着 清理 不 得 不 异步 地 发 生 。 事 务 不 能 够 清除 自己 留 下 的 垃圾 并 且 在 
COMMIT/ROLLBACK 时 处 理 死 亡 行 也 为 时 过 早 。 
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这 个 问题 的 解决 方案 就 是 VACUUM: 


test=# h VACUUM 
Command: VACUUM 
Description: garbage-collect and optionally analyze a database 


Syntax: 

VACUUM [ ( { FULL | FREEZE | VERBOSE | ANALYZE } [, ...] ) |] 
[ table name [(column name [, ...] ) ] ] 

VACUUM [ FULL ] [ FREEZE ] [ VERBOSE ] [ table name ] 

VACUUM [ FULL |] [ FREEZE ] [ VERBOSE ] ANALYZE [ table name 
[ (column name[, ...] ) ] ] 


VACUUM 将 访问 所 有 可 能 包含 修改 的 页 面 并 且 找 出 所 有 的 死亡 空间 。 找 到 的 空闲 空 
间 将 交 由 该 关系 的 空闲 空间 映射 (FSM) 跟踪 。 
注意 在 大 部 分 情况 下 ，VACUUM 将 不 会 收缩 表 的 尺寸 。 相 反 ， 它 将 在 现 有 的 存储 文 
件 中 跟踪 并 且 寻 找 空 闲 空间 。 
人 在 VACUUM 后 ， 表 通常 将 具有 操作 前 相同 的 尺寸 。 如 果 在 一 个 表 的 末尾 没 
有 合法 的 行 ， 在 极 少 的 情况 下 文件 尺寸 会 减 小 ， 但 这 不 是 规则 而 是 一 种 特例 。 
这 对 最 终 用 户 的 意义 将 在 2.7.2 节 中 介绍 。 


2.7.1 配置 VACUUM 和 autovacuum 

















回 到 PostgreSQL 项 目的 早期 ， 人 们 不 得 不 手工 运行 VACUUM。 幸 运 地 是 这 已 经 成 
为 过 去 式 ， 现 如 今 的 管理 员 们 可 以 依靠 一 个 被 称 作 autovacuum 的 工具 ， 它 是 PostgreSQL 
服务 器 基础 设施 的 一 部 分 。autovacuum 会 自动 地 处 理 清理 并 且 在 后 台 工 作 ， 它 每 一 分 钟 
( 见 postgresql.conf 中 的 autovacuum_naptime = 1) 醒 来 一 次 并 且 检 查 是 否 有 工作 要 做 。 如 
果 有 工作 要 做 ，autovacuum 将 派生 出 最 多 3 个 ( 见 postgresql.conf 中 的 autovacuum max 
workers) 工作 者 进程 。 
主要 的 问题 是 : 什么 时 候 autovacuum 会 触发 一 个 工作 者 进程 的 创建 ? 

实际 上 autovacuum 进程 并 不 自己 派生 进程 。 相 反 ， 它 会 告诉 主 进程 来 做 这 

件 事 。 这 是 为 了 防止 在 失败 的 情况 下 产生 僵尸 进程 ， 并 且 提 高 重 棒 性 。 

这 个 问题 的 答案 还 可 以 在 postgresql.conf 中 找到 : 


autovacuum vacuum threshold = 50 

















autovacuum analyze threshold = 50 
autovacuum vacuum scale factor = 0.2 


autovacuum analyze scale factor = 0.1 
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autovacuum_ Vacuum scale _factor 告诉 PostgreSQL: 如 果 一 个 表 中 20% 的 数据 已 经 被 
改过 ， 那 么 它 就 值得 被 清理 。 麻 烦 在 于 ， 如 果 一 个 表 只 由 一 行 构成 ， 一 次 更 改 就 已 经 是 
100% 。 派 生出 一 个 完整 的 进程 来 只 清理 一 行 绝对 是 没有 意义 的 。 因 此 ， 
autovacuum _vacuuum threshold 会 要 求 我 们 需要 20% 的 修改 并 且 那 20% 必 须 有 至 少 50 
行 。 否 则 ，VACUUM 不 会 开始 。 在 进行 优化 器 统计 信息 创建 时 也 使 用 了 同样 的 机 制 。 至 
少 需要 10% 的 修改 并 且 至 少 50 行 才 能 触发 对 优化 器 统计 信息 的 更 新 。 在 理想 情况 下 ， 
autovacuum 会 在 一 次 普通 的 VACUUM 中 创建 新 的 统计 信息 以 避免 对 表 不 必要 的 访问 。 


1， 探 究 事务 回 卷 相关 的 问题 
postgresql.conf 中 还 有 另外 两 个 需要 着 重 理解 的 设置 


autovacuum freeze max age = 200000000 

autovacuum multixact freeze max age = 400000000 

为 了 理解 整个 问题 ， 了 解 PostgreSQL 怎样 处 理 并 发 是 很 重要 的 。PostgreSQL 的 事务 
机 制 建 立 在 对 事务 ID 的 检查 以 及 事务 所 处 状态 的 基础 之 上 。 

一 个 例子 : 如 果 我 是 ID 为 4711 的 事务 并 且 你 正好 是 4712， 我 将 看 不 到 你 ， 因 为 你 
还 在 运行 中 。 如 果 我 是 ID 为 4711 的 事务 而 你 是 3900， 如 果 你 已 经 提交 ， 我 将 能 够 看 到 
你 ， 而 如 果 你 失败 ， 我 将 忽略 你 的 操作 。 

接着 麻烦 就 来 了 : 事务 ID 是 有 限 的 ， 不 是 我 们 可 以 任意 挥霍 的 。 在 某 个 时 候 ， 它 们 
将 会 开始 回 卷 。 这 就 意味 着 事务 号 5 可 能 实际 上 在 事务 号 800000000 之 后 。PostgreSQL 
是 怎么 知道 哪 一 个 在 前 ? 它 通 过 存储 一 个 水 位 标志 来 做 到 这 一 点 。 在 某 个 时 候 ， 那 些 水 
位 标志 会 被 调整 ， 并 且 这 正好 就 是 VACUUM 开始 介入 的 时 候 。 通 过 运行 VACUUM (或 
者 autovacuum)， 用 户 可 以 确保 水 位 标志 被 调整 后 ， 总 是 有 足够 的 未 来 事务 ID 可 用 。 

不 是 每 一 个 事务 都 会 增加 事务 ID 计数 器 。 只 要 一 个 事务 还 在 读 取 ， 它 将 只 有 一 个 虚 
拟 事务 ID。 这 保证 了 事务 ID 不 会 增加 得 太 快 。 

autovacuum freeze max age 定义 了 在 执行 一 次 VACUUM 操作 来 阻止 表 中 事务 ID 回 
卷 之 前 ， 一 个 表 的 pg_class.relfrozenxid 域 能 达到 的 最 大 事务 数 〈 年 龄 )。 这 个 值 相 当 低 ， 
因为 它 也 影响 着 clog 清理 (clog 或 者 提交 日 志 是 一 个 为 每 个 事务 存储 2 位 的 数据 结构 ， 
这 2 位 表示 事务 是 运行 中 、 已 中 止 、 已 提交 或 是 正在 子 事务 中 )。 

autovacuum mnultixact freeze max age 配置 在 执行 一 次 VACUUM 操作 来 阻止 表 中 
multixact ID 回 卷 之 前 ， 一 个 表 的 pg_class.relminmxid 域 能 达到 的 最 大 年 龄 (以 multixact 
事务 个 数 计 )。 冻 结 元 组 是 一 种 重要 的 性 能 问题 ， 在 第 6 章 中 会 有 更 多 关于 它 的 内 容 。 
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2. 关于 VACUUM FULL 的 一 点 建议 


除了 普通 的 VACUUM， 还 可 以 使 用 VACUUM FULL。 不 过 ， 有 一 点 笔者 必须 要 强 
调 : VACUUM FULL 实际 上 会 锁 住 表 并 且 重 写 整个 关系 。 如 果 是 一 个 小 的 表 ， 这 可 能 不 
成 问题 。 但 如 果 表 很 大 ， 这 种 表 锁 会 影响 用 户 数 分 钟 之 久 ! VACUUM FULL 会 阻塞 即将 
到 来 的 写 操作 并 且 有 些 人 会 觉得 数据 库 看 上 去 已 经 宕 掉 了 。 因 此 ， 关 于 这 个 问题 人 们 已 
经 给 出 了 很 多 警示 。 

要 消除 掉 VACUUM FULL， 笔 者 建议 读者 去 看 看 pg_squeeze (http://www.cybertec.at/ 
introducing-pg_squeeze-a-postgresql-extension-to-auto-rebuild-bloated-tables/ )， 它 可 以 重 写 


一 个 表 而 不 用 阻塞 写 操作 。 
2.7.2 ”观察 工作 中 的 VACUUM 


在 这 些 介 绍 之 后 ， 是 时 候 看 看 运转 中 的 VACUUM 了 。 之 所 以 在 这 里 包括 这 一 节 ， 是 
因为 笔者 作为 一 个 PostgreSQL 顾问 和 支持 人 员 (http://postgresql-support.de/) 的 实践 表 
明 ， 大 部 分 人 对 存储 端 发 生 的 事情 只 有 着 非常 模糊 的 理解 。 

下 面 会 再 次 强调 这 一 点 ， 在 大 部 分 情况 下 VACUUM 将 不 会 收缩 你 的 表 ， 空 间 通常 不 
会 被 交还 给 文件 系统 。 

这 里 是 笔者 的 例子 : 


CREATE TABLE t test (id int) WITH (autovacuum enabled = off); 








INSERT INTO t test 
SELECT * FROM generate series(1, 100000); 


其 想法 是 创建 一 个 包含 100000 行 的 简单 表 。 注 意 可 以 对 特定 的 表 关 闭 autovacuum， 
但 对 于 大 部 分 应 用 这 通常 不 是 个 好 主意 。 不 过 ， 在 一 些 极限 情况 中 autovacuum_enabled = 
off 是 有 意义 的 。 只 要 考虑 一 个 生命 周期 很 短 的 表 。 如 果 开 发 者 已 经 知道 整个 表 将 在 数秒 
之 后 被 删除 ， 对 它 清理 元 组 就 没有 意义 了 。 在 数据 仓库 中 ， 如 果 用 户 把 表 用 作 暂 存 区 就 
会 是 这 样 。 在 这 个 例子 中 ，VACUUM 被 关闭 以 保证 不 会 在 后 台 发 生 其 他 事情 ， 读 者 所 看 
到 的 都 是 由 笔者 触发 而 不 是 被 某 个 其 他 进程 所 执行 。 

首先 检查 该 表 的 尺寸 : 


test=# SELECT pg size pretty(pg relation size('t test')); 





pg size pretty 
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pg_relation_size 返回 一 个 表 的 字 节 尺寸 ， 而 pg_size_pretty 将 得 到 这 个 数字 ， 并 且 把 
它 转 换 成 人 类 可 读 的 。 
然后 该 表 中 的 所 有 行 都 将 被 更 新 : 


test=# UPDRTE 七 test SET id = id + 17 
UPDATE 100000 


所 发 生 的 事情 对 理解 PostgreSQL 非常 重要 ， 数 据 库 引擎 不 得 不 复制 所 有 的 行 。 为 什 
么 会 这 样 ? 首先 ， 我 们 不 知道 该 事务 是 否 将 会 成 功 ， 因 此 这 些 数 据 不 能 被 覆盖 。 第 二 个 
重要 的 方面 是 ， 可 能 有 一 个 并 发 事务 仍然 在 用 这 些 数据 的 旧版 本 。 


(人 UPDATE 操作 将 会 复制 行 。 


逻辑 上 ， 该 表 的 尺寸 将 会 在 修改 之 后 变 得 更 大 : 


test=# SELECT pg_ size pretty(pg relation size('t test')); 
pg_size pretty 


7080 kB 
(1 row) 


在 UPDATE 之 后 ， 人 们 可 能 会 尝试 把 空间 还 给 文件 系统 : 


test=# VACUUM t test; 
VACUUM 


如 前 所 述 ， 大 部 分 情况 下 VACUUM 不 把 空间 还 给 文件 系统 。 相 反 ， 它 允许 空间 被 重 
用 。 因 此 ， 该 表 根 本 不 会 收缩 : 


test=# SELECT pg size pretty(pg relation size('t test')); 
pg size pretty 


H 





7080 kB 

(1 row) 

不 过 ， 下 一 次 UPDATE 不 会 让 该 表 长 大 ， 因 为 它 会 用 掉 该 表 中 的 空闲 空间 。 只 有 第 
二 次 的 UPDATE 会 让 该 表 再 次 长 大 ， 因 为 所 有 的 空间 都 用 完了 ， 需 要 额外 的 存储 空间 : 

test=# UPDATE 七 test SET id = id + 1; 


UPDATE 100000 
test=# SELECT pg size pretty(pg relation size("t test')); 








pg_size_Pretty 
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test=# UPDATE t test SET id = id + 1; 

UPDATE 100000 

test=# SELECT pg size pretty(pg relation size('t test')); 
pg_ size pretty 


(1 row) 


如 果 笔 者 必须 选择 一 项 读者 在 读 完 本 书后 应 该 记 住 的 内 容 ， 这 算 一 项 。 理 解 存储 通 


常 是 性 能 和 管理 的 关键 。 
让 我 们 运行 更 多 的 查询 : 
VACUUM t test; 


UPDATE 七 test SET id = id+1; 
VACUUM t test; 


尺寸 还 是 没有 改变 。 让 我 们 看 看 表 里 有 什么 : 


test=# SELECT ctid, * FROM t test ORDER BY ctid DESC; 


ctid 1 id 
HE 
人 (326 
(L3275 A457 0 
(1327,44) | 110 


(884,20) | 99798 
(884,19) | 99797 


ctid 是 行 在 磁盘 上 的 物理 位 置 。 通 过 使 用 ORDER BY ctid DESC， 用 户 将 按照 物理 顺 
序 从 后 向 前 读 到 该 表 。 为 什么 要 关心 这 一 点 ?原因 是 在 该 表 的 末尾 有 一 些 非常 小 的 值 和 


非常 大 的 值 。 如 果 它 们 被 删除 会 发 生 什么 ? 


test=# DELETE FROM 七 test WHERE id > 99000 OR id < 1000; 
DELETE 1999 

test=# VACUUM t test; 

VACUUM 

test=# SELECT pg size pretty(pg relation size('t test")); 
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pg size pretty 


3504 kB 
(1 row) 
尽管 只 有 2% 的 数据 被 删除 ， 该 表 的 尺寸 却 下 降 了 三 分 之 二 。 原 因 在 于 ， 如 果 
VACUUM 只 在 该 表 中 的 特定 位 置 之 后 寻找 死亡 行 ， 它 可 以 把 空间 还 给 文件 系统 。 这 是 唯 
一 一 种 可 以 看 到 表 尺 寸 下 降 的 情况 。 当 然 ， 普 通用 户 无 法 控制 数据 在 磁盘 上 的 物理 位 
置 。 因 此 ， 存 储 消耗 将 很 可 能 保持 相同 ， 除 非 所 有 的 行 都 被 删除 。 
为 什么 有 这 么 多 小 值 和 大 值 在 该 表 的 末尾 ? 在 该 表 最 初 被 100000 个 行 填 
充 之 后 ， 最 后 一 个 块 并 没有 被 完全 填 满 ， 因 此 第 一 次 的 UPDATE 将 用 更 改 填 满 
最 后 一 块 。 这 自然 把 该 表 的 末尾 搅乱 了 一 点 。 在 这 个 精心 布置 的 例子 中 ， 这 就 
是 在 表 末 尾 出 现 如 此 怪异 布局 的 原因 。 
在 真实 世界 的 应 用 中 ， 这 种 现象 的 影响 没有 得 到 足够 的 重视 。 没 有 真正 理解 存储 是 
不 可 能 进行 性 能 调 优 的 。 
2.7.3 利用 snapshot too old 




















VACUUM 做 得 很 好 并 且 它 将 根据 需要 回收 空闲 空间 。 但 是 何 时 VACUUM 才能 真正 
清理 掉 行 并 且 把 它们 转变 成 空闲 空间 ? 规则 是 这 样 : 如果 一 行 再 也 不 能 被 任何 人 看 见 ， 它 
就 能 被 回收 。 实 际 上 这 意味 着 最 老 的 事务 都 看 不 见 的 部 分 就 可 以 被 认为 是 真正 死亡 了 。 

这 还 意味 着 真正 的 长 事务 可 以 把 清理 推迟 相当 长 的 时 间 ， 由 此 带 来 的 后 果 就 是 表 膨 
胀 。 表 将 会 超 比 例 增长 并 且 性 能 将 会 趋向 于 衰退 。 

幸运 地 是 ，PostgreSQL 9.6 有 一 个 很 好 的 特性 允许 管理 员 聪 明 地 限制 一 个 事务 的 时 
间 。Oracle 管理 员 会 非常 熟悉 snapshot too old 错误 。 从 PostgreSQL 9.6 开始 ， 也 有 了 这 种 
背 误 消 息 。 但 是 它 更 像 是 一 种 特性 ， 而 不 是 由 于 错误 配置 而 导致 的 意外 的 副作用 (Oracle 
中 就 是 这 样 )。 

为 了 限制 快照 的 生存 时 间 ， 可 以 使 用 postgresql.conf 中 的 一 个 设置 : 


old snapshot threshold = -1 
# lmin-60d; -1 disables; 0 is immediate 





如 果 设 置 了 这 个 变量 ， 事 务 将 会 在 一 定量 的 时 间 之 后 失败 。 注 意 这 个 设置 是 在 实例 
级 别 ， 并 且 不 能 在 会 话 中 设置 。 通 过 限制 一 个 事务 的 尺寸 ， 超 长 事务 带 来 的 风险 将 会 急 
剧 下 降 。 





32» 由 浅 入 深 PostgreSQL 


2.8 总 结 


在 本 章 中 ， 读 者 学 到 了 有 关 事 务 、 锁 定 及 其 逻辑 含义 ， 以 及 PostgreSQL 事务 机 制 用 
于 存储 的 一 般 架 构 ， 还 有 相关 的 管理 。 读 者 也 看 到 了 行 是 如 何 被 锁定 的 以 及 存在 哪些 
特性 。 

在 第 3 章 中 ， 读 者 将 学 习 数 据 库 工作 中 最 重要 的 主题 一 一 索引 。 读 者 会 学 到 关于 
PostgreSQL 查询 优化 器 的 内 容 以 及 几 种 索引 类 型 和 它们 的 行为 。 








第 3 章 使 用 索引 


在 第 2 章 中 ， 读 者 学 到 了 有 关 并 发 和 锁定 的 内 容 。 在 本 章 中 我 们 将 直面 索引 。 这 一 
主题 的 重要 性 怎么 强调 也 不 过 分 ， 索 引 是 (并 且 很 可 能 将 总 是 ) 每 一 个 数据 库 工 程 师 职 
业 生 涯 中 最 重要 的 主题 之 一 。 

在 经 历 了 17 年 专业 的 全 职 PostgreSQL 咨询 和 24X7 技术 支持 生涯 之 后 ， 笔 者 可 以 肯 
定 一 件 事情 : 糟糕 的 索引 是 糟糕 性 能 的 主因 。 当 然 ， 调 整 内 存 参数 等 也 很 重要 。 但 是 ， 
如 果 索 引 没 有 被 正确 使 用 ， 一 切 都 将 是 徒劳 。 一 个 缺失 索引 是 无 可 替代 的 。 因 此 ， 笔 者 
将 一 整 章 的 篇 幅 单独 留 给 索引 ， 以 便 让 读者 尽 可 能 多 地 了 解 索引 。 

在 本 章 中 ， 读 者 将 学 到 下 面 这 些 主题 : 

什么 时 候 PostgreSQL 使 用 索引 ? 
优化 器 如 何 工 作 ? 
有 些 什 么 类 型 的 索引 以 及 它们 怎么 工作 ? 
使 用 你 自己 的 索引 策略 。 
结束 本 章 后 ， 读 者 将 能 理解 在 PostgreSQL 中 如 何 有 效 地 使 用 索引 。 


3.1 理解 简单 查询 和 代价 模型 


在 本 节 中 ， 我 们 将 开始 使 用 索引 。 为 了 便于 展示 ， 我 们 需要 一 些 测试 数据 。 下 面 的 
代码 片段 展示 如 何 轻易 地 创建 这 些 数据 : 
test=# CREATE TABLE t test (id serial, name text); 
CREATE TABLE 
test=# INSERT INTO t test (name) SELECT '‘'hans' 
FROM generate series(1, 2000000); 
INSERT 0 2000000 
test=# INSERT INTO 七 test (name) SELECT "paul" 
FROM generate series(1, 2000000); 
INSERT 0 2000000 


第 一 行 创建 了 一 个 简单 的 表 ， 其 中 用 到 了 两 个 列 : 一 个 自 增 列 ， 它 保存 增长 着 的 数 
字 ， 另 一 个 列 则 用 静态 值 填充 。 
generate_series 函数 将 生成 从 1 到 2 百 万 的 数字 。 因 此 在 这 个 例子 中 ， 
会 为 hans 和 paul 都 创建 2 百 万 个 静态 值 。 
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总 计 有 4 百 万 行 被 增加 到 表 中 : 


test=# SELECT name, Count (*) FROM t test GROUP BY 1; 
name | count 
Ce ee 
hans | 2000000 
paul | 2000000 
(2 rows) 


这 4 百 万 行 有 一 些 很 好 的 性 质 : ID 是 升序 的 并 且 只 有 两 种 不 同 的 名 字 。 
现在 让 我 们 运行 一 个 简单 的 查询 : 
test=# \timing 


Timing is on. 
test=# SELECT * FROM t test WHERE id = 432332; 


id | name 
二 = 
432332 | hans 

(1 row) 


Time: 119.318 ms 

在 这 种 情况 下 ，\timing 命令 将 告诉 psql 显示 一 个 查询 的 运行 时 间 。 注 意 这 不 是 在 服 
务 器 上 真正 的 执行 时 间 ， 而 是 psql 测量 的 时 间 。 在 查询 非常 短 的 情况 下 ， 网 络 延 迟 可 能 
会 是 总 时 间 中 占 比 大 的 组 成 部 分 ， 因 此 必须 被 考虑 在 内 。 


3.1.1 使 用 EXPLAIN 


在 这 个 例子 中 ， 读 取 4 百 万 行 用 了 超过 100 毫秒 的 时 间 。 从 性 能 的 角度 来 看 ， 这 完 
全 是 一 场 灾 难 。 为 了 找 出 什么 地 方 不 对 ，PostgreSQL 提供 了 EXPLAIN 命令 : 


test=# \h EXPLAIN 

Command: EXPLAIN 

Description: show the execution plan of a statement 
Syntax: 

EXPLAIN [ ( option [, ...] ) ] statement 

EXPLAIN [ ANALYZE ] [ VERBOSE ] statement 


where option can be one of: 
ANALYZE [ boolean ] 


VERBOSE [ boolean ] 
COSTS [ boolean ] 
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BUFFERS [ boolean ] 
TIMING [ boolean ] 
FORMAT { TEXT | XML | JSON | YAML } 
感觉 一 个 查询 执行 得 不 好 时 ，EXPLAIN 将 帮助 我 们 揭示 真正 的 性 能 问题 。 
它 是 这 样 工作 的 : 
test=# EXPLAIN SELECT * FROM t test WHERE id = 432332; 
QUERY PLAN 


Gather (cost=1000.00. .43463.92 rows=1 width=9) 
Workers Planned: 2 
-> parallel Seq Scan on Et test 
(cost=0.00..42463.82 rows=1 width=9) 
Filter: (id = 432332) 

(4 rows) 

读者 在 这 个 列表 中 看 到 的 就 是 所 谓 的 执行 计划 。 在 PostgreSQL 中 ， 一 个 SQL 语句 将 
被 分 成 4 个 阶段 执行 。 下 列 组 件 会 参与 其 中 : 

@ 解析 器 将 检查 语法 错误 以 及 明显 的 问题 。 

@ 重 写 系统 负责 规则 (视图 等 )。 

@ ”优化 器 将 解决 如 何以 最 有 效 的 方法 执行 一 个 查询 并 且 制 订 出 一 个 计划 。 

@ 优化 器 提供 的 计划 将 被 执行 器 用 来 最 终 创 建 结 果 。 

EXPLAIN 的 目的 是 看 看 计划 器 给 出 什么 样 的 东西 来 高 效 地 运行 查询 。 在 笔者 的 例 
子 中 ，PostgreSQL 将 使 用 一 个 并 行 顺序 扫描 ， 这 意味 着 两 个 工作 者 将 合作 来 处 理 过 滤 
条 件 。 得 到 的 局 部 结果 接 下 来 通过 一 个 称 为 收集 节点 的 东西 联合 起 来 ， 收 集 节点 在 
PostgreSQL 9.6 中 作为 并 行 查询 架构 的 一 部 分 引入 。 如 果 读 者 更 加 细致 地 观察 这 个 计划 ， 
将 会 看 到 PostgreSQL 在 该 计划 的 每 个 阶段 预期 得 到 的 行 数 〈 在 这 个 例子 中 ，rows = 1， 即 
将 返回 1 行 )。 

在 PostgreSQL 9.6 中 ， 并 行 工作 者 的 数量 将 由 表 的 尺寸 决定 。 一 个 操作 
越 大 ，PostgreSQL 就 将 发 动 更 多 的 并 行 工 作者 。 对 于 一 个 非常 小 的 表 ， 并 
行 机 制 不 会 被 使 用 ， 因 为 它 会 带 来 太 多 开销 。 


并 行 并 非 必 不 可 少 ， 通 过 将 下 面 的 变量 设置 为 0， 总 是 可 以 将 并 行 工作 者 的 数量 降低 
成 PostgreSQL 9.6 之 前 的 行为 : 


I 








test=# SET max parallel workers per gather TO 0; 
SET 
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注意 这 种 改变 没有 副作用 ， 因 为 它 只 在 用 户 的 会 话 中 有 效 。 当 然 用 户 也 可 以 决定 在 
postgresql.conf 中 更 改 该 变量 ， 但 笔者 不 建议 这 样 做 ， 因 为 那样 会 损失 很 多 由 并 行 查询 带 
来 的 性 能 。 


3.1.2 深究 PostgreSQL 代价 模型 
如 果 只 有 一 个 CPU 被 使 用 ， 执 行 计划 看 起 来 将 会 像 这 样 : 


test=# EXPLAIN SELECT * FROM t test WHERE id = 432332; 
QUERY PLAN 


Seq Scan on t test (cost=0.00..71622.00 rows=1 width=9) 
Filter: (id = 432332) 

(2 rows) 

PostgreSQL 将 顺序 读 取 顺序 扫描 〉 整 个 表 并 且 应 用 过 滤 条 件 。 它 预计 该 操作 会 花 
费 71622 惩罚 点 。 这 是 什么 意思 呢 ? 惩罚 点 〈 或 者 说 代价 ) 通常 是 一 种 抽象 概念 。 它 们 
被 用 来 比较 执行 查询 的 不 同方 式 。 如 果 一 个 查询 可 以 被 执行 器 以 很 多 不 同 的 方式 执行 ， 
PostgreSQL 将 选取 承诺 最 低 代 价 的 执行 计划 。 现 在 的 问题 是 : PostgreSQL 是 怎样 得 到 
71622 点 的 ? 

原理 如 下 : 


test=# SELECT pg relation size('t test') / 8192.0; 
?column? 


























21622.000000000000 

(1 row) 

pg_relation_size 函数 将 会 返回 该 表 以 字 节 为 单位 的 大 小 。 在 给 定 的 例子 中 ， 可 以 看 到 
这 个 关系 由 21622 个 块 (每 个 大 约 8000 字 节 ) 构成 。 根 据 代价 模型 ，PostgreSQL 将 会 为 
它 必须 顺序 读 取 的 每 一 个 块 加 上 代价 1。 

影响 这 个 过 程 的 配置 参数 是 : 

test=# SHOW seq page cost; 


seq page cost 


(1 row) 


不 过 ， 从 磁盘 读 取 一 大 堆 块 并 非 我 们 要 做 的 所 有 事情 。 还 需要 通过 CPU 应 用 过 滤 条 





册 
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件 并 且 发 送 那些 行 。 这 里 有 两 个 参数 负责 相应 的 代价 : 


test=# SHOW cpu tuple cost; 
cpu tuple cost 





(1 row) 
test=# SHOW cpu operator cost; 
cpu operator cost 


这 会 导致 下 面 的 计算 : 


test=# SELECT 21622*1 + 4000000*0.01 + 4000000*0.0025; 
?column? 


71622.0000 
(1 row) 
如 你 所 见 ， 这 正好 是 我 们 在 计划 中 看 到 的 数字 。 代 价 由 一 个 CPU 的 部 分 和 一 个 VO 
的 部 分 组 成 ， 它 们 都 将 被 转变 成 为 一 个 单一 的 数字 。 这 里 的 重点 是 代价 与 实际 执行 没有 
关系 ， 因 此 不 可 能 把 代价 解读 成 毫秒 。 计 划 器 给 出 的 数字 仅仅 只 是 一 个 估计 值 。 
当然 ， 还 有 比 这 个 简短 例子 中 提 到 的 参数 更 多 的 参数 。PostgreSQL 还 有 一 些 用 于 索 
引 相 关 操 作 的 特殊 参数 。 
@ random page cost = 4: 如 果 PostgreSQL 使 用 一 个 索引 ， 通 常会 涉及 很 多 随机 
IO。 在 传统 的 旋转 型 磁盘 上 ， 随 机 读 比 顺序 读 重要 得 多 ， 因 此 PostgreSQL 也 将 
相应 地 解释 它们 。 注 意 在 SSD 上 ， 随 机 读 和 顺序 读 之 间 的 差异 已 经 不 再 存在 ， 
因此 可 以 在 postgresql.conf 文件 中 设置 random page_cost= 1。 
@ cpu index tuple cost = 0.005: 如 果 使 用 了 索引 ，PostgreSQL 还 将 考虑 一 些 索引 
的 CPU 代价 。 
如 果 用 户 使 用 并 行 查 询 ， 还 有 更 多 代价 参数 。 
@ parallel tuple cost = 0.1: 这 个 参数 定义 了 从 一 个 并 行 工作 者 进程 向 另 一 个 进程 
传输 一 个 元 组 的 代价 。 它 基本 上 用 于 解释 在 并 行 架 构 内 部 移动 元 组 的 开销 。 
@ parallel setup_cost = 1000.0: 这 个 参数 调整 发 动 一 个 工作 者 进程 的 代价 。 当 然 ， 
启动 进程 来 并 行 运行 查询 不 是 免费 的 ， 因 此 这 个 参数 试图 建 模 那 些 与 进程 管理 
相关 的 代价 。 
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@ min parallel relation size = 8 MB: 这 个 参数 定义 了 考虑 使 用 并 行 查询 的 表 的 最 
小 尺寸 。 一 个 表 长 得 越 大 ，PostgreSQL 就 将 使 用 更 多 的 CPU。 表 的 尺寸 必须 成 
为 之 前 3 倍 才 会 多 出 一 个 工作 者 进程 。 


3.1.3 部署 简单 的 索引 


发 动 更 多 工作 进程 来 扫描 非常 大 的 表 有 时 候 并 不 能 解决 问题 。 读 取 整 个 表 只 为 寻找 
一 行 通常 也 不 是 什么 好 主意 。 因 此 ， 我 们 需要 创建 索引 : 
test=# CREATE INDEX idx id ON t test (id) 
CREATE INDEX 
test=# SELECT * FROM t test WHERE id = 43242; 
id | name 
才 三 二 三 三 三 二 华 二 三 二 二 三世 
43242 | hans 
(1 row) 
Time: 0.259 ms 


PostgreSQL 使 用 Lehman-Yao 的 高 并 发 性 B- 树 作为 标准 索引 。 连 同一 些 PostgreSQL 
的 专门 优化 一 起 ， 这 些 树 为 最 终 用 户 提 供 了 优秀 的 性 能 。 最 重要 的 一 点 是 ，Lehman-Yao 
让 用 户 能 在 同一 时 间 在 同一 个 索引 上 运行 很 多 操作 〈 读 和 写 )， 这 有 助 于 极 大 地 提升 知 
吐 量 。 


但 是 ， 索 引 也 不 是 白 用 的 : 








test=# \di+ 

List of relations 
Schema | Name | Type | Owner | Table | Size | Description 
一 一- 一 -一 十 一 一 一 一 一 一 一 一 十 一 一 一 一 一 一 一 十 一 一 一 一 一 一 一 十 一 一 一 一 一 一 一 一 十 一 一 一 一 一 一 一 十 一 一 一 一 一 一 一 一 一 一 一 一 一 
public | Ldx id | indezx | hs Lt test | 36 MB 
(1 row) 


如 你 所 见 ， 我 们 的 索引 包含 的 4 百 万 行 ， 它 将 用 掉 86MB 的 磁盘 空间 。 除 此 之 外 ， 
对 于 该 表 的 写 入 将 会 变 慢 ， 因 为 索引 必须 一 直 被 保持 同步 。 


3.1.4 ”使 用 排序 输出 
B- 树 索引 并 非 只 对 查找 行 有 用 。 它 们 也 可 用 来 给 下 一 阶段 处 理 提供 排序 好 的 数据 : 


test=# EXPLAIN SELECT * FROM t test ORDER BY id DESC LIMIT 10; 
QUERY PLAN 




















第 3 章 使 用 索引 “39。 


Limit (cost=0.43..0.74 rows=10 width=9) 
-> Index Scan Backward using idx id on t test 
(cost=0.43..125505.43 rows=4000000 width=9) 
(2 rows) 


在 这 种 情况 中 ， 索 引 已 经 按 正 确 的 顺序 返回 了 数据 ， 因 此 不 需要 再 对 整个 数据 集 排 
序 。 读 取 索 引 的 最 后 10 行 就 足够 回答 这 个 查询 了 。 实 际 上 ， 这 意味 着 可 以 在 零点 几 毫 秒 
内 找到 一 个 表 中 的 前 N 行 。 

不 过 ，ORDER BY 不 是 唯一 要 求 排序 输出 的 操作 。min 和 max 函数 也 都 与 排序 输出 
有 关 ， 因 此 索引 也 可 以 被 用 来 加 速 这 两 个 操作 。 这 里 有 一 个 例子 : 

test=# explain SELECT min(id), max(id) FROM t test; 

QUERY PLAN 
Result (cost=0.93..0.94 rows=1l1 width=8) 
InitPlan 1 (returns $0) 
-> Limit (cost=0.43..0.46 rows=1 width=4) 
-> Index Only Scan using idx id on t test 
(cost=0.43..135505.43 rows=4000000 width=4) 
Index Cond: (id IS NOT NULL) 
InitPlan 2 (returns $1) 
-> Limit (cost=0.43..0.46 rows=1 width=4) 
-> Index Only Scan Backward using idx id on t test t test 1 
(cost=0.43..135505.43 rows=4000000 width=4) 
Index Cond: (id IS NOT NULL) 











(9 rows) 


在 PostgreSQL 中 ， 一 个 索引 (或 者 更 准确 点 说 是 一 棵 B- 树 ) 可 以 以 正常 的 顺序 或 者 
反 向 顺序 被 读 取 。 现 在 的 情况 是 : 一 棵 B- 树 可 以 被 看 成 是 一 个 已 排序 的 列表 。 因 此 自然 
是 最 小 值 在 开头 而 最 大 值 在 结尾 。 因 此 ，min 和 max 非常 适合 用 索引 来 加 速 。 

在 SQL 中 ， 很 多 操作 依赖 于 排序 输入 。 因 此 ， 理 解 那些 操作 是 必要 的 ， 因 为 它们 会 
对 索引 有 很 多 严重 的 影响 。 


3.1.5 ”一 次 使 用 多 个 索引 
到 目前 为 止 ， 读者 已 经 看 到 了 一 次 使 用 一 个 索引 的 例子 。 不 过 ， 在 很 多 真实 世界 的 
情况 中 ， 这 还 远 远 不 够 。 有 些 情 况 会 要 求 在 数据 库 中 使 用 更 多 的 逻辑 。 


PostgreSQL 人 允许 在 单个 查询 中 使 用 多 个 索引 。 当 然 ， 如 果 同 时 有 很 多 列 被 查询 这 才 
有 意义 。 但 并 非 总 是 如 此 ， 也 可 能 会 发 生 同一 个 索引 被 多 次 使 用 来 处 理 同 一 列 的 情况 。 
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这 里 有 一 个 例子 : 


test=# explain SELECT * FROM t test WHERE id = 30 OR id = 50; 
QUERY PLAN 


Bitmap Heap Scan on t test (cost=8.88..16.85 rows=2 width=9) 
Recheck Cond: ((id = 30) OR (id = 50)) 
-> BitmapOr (cost=8.88..8.88 rows=2 width=0) 
-> Bitmap Index Scan on idx idv (cost=0.00..4.44 rows=1 width=0) 
Index Cond: (id = 30) 
-> Bitmap Index Scan on idx id (cost=0.00..4.44 rows=1 width=0) 
Index Cond: (id = 50) 
(7 rows) 


这 里 的 重点 是 有 两 个 地 方 需要 id 列 。 首 先 该 查询 会 找 30， 然 后 又 会 找 50。 如 你 所 
见 ，PostgreSQL 将 会 进行 所 谓 的 位 图 扫描 。 
位 图 扫描 和 位 图 索引 (有 Oracle 背景 的 人 可 能 会 知道 ) 并 不 相同 。 它 
《人 们 是 两 种 完全 不 同 的 概念 ; 并 且 没 有 任何 共同 点 。 位 图 索引 是 Oracle 中 的 
一 种 索引 类 型 ， 而 位 图 扫描 基本 上 是 一 种 扫描 方法 。 


在 位 图 扫描 背后 的 思想 是 ，PostgreSQL 将 首先 扫描 第 一 个 索引 ， 收 集 含 有 数据 的 块 
的 一 个 列表 。 pet td ee i 有 多 少 个 索引 就 会 这 样 
做 多 少 次 。 在 OR 的 情况 下 ， 这 些 列表 会 被 统一 ， 留 给 我 们 一 个 由 含有 数据 的 块 构成 的 大 
列表 。 最 后 才 会 使 用 这 个 列表 来 扫描 表 以 检索 出 那些 块 。 现 在 的 问题 是 ，PostgreSQL 已 
经 检索 出 的 数据 比 需要 的 更 多 。 在 我 们 的 情况 中 ， 查 询 将 查找 两 行 ， 但 是 位 图 扫描 可 能 
返回 的 是 几 个 块 。 因 此 ， 执 行 器 将 进行 所 谓 的 复查 来 过 滤 掉 那些 不 满足 条 件 的 行 。 

位 图 扫描 也 可 以 用 于 AND 条 件 或 者 AND 与 OR 的 混合 条 件 。 不 过 ， 如 果 
PostgreSQL 看 到 一 个 AND 条 件 ， 它 不 一 定 会 强制 用 位 图 扫描 。 让 我 们 假设 有 一 个 查询 查 
找 每 一 个 生活 在 奥地利 的 人 以 及 一 个 有 特定 ID 的 人 。 这 里 使 用 两 个 索引 实际 上 没有 意 
义 ， 因 为 在 搜索 该 ID 后 实际 上 不 会 有 多 少数 据 剩 下 来 。 扫 描 两 个 索引 会 是 更 加 昂贵 的 方 
法 ， 因 为 有 8 百 万 人 《包括 我 自己 ) 生活 在 奥地利 ， 从 性 能 的 观点 来 看 ， 把 这 么 多 行 读 
进来 就 为 了 查找 一 个 人 实在 是 没有 意义 。 好 消息 是 PostgreSQL 的 优化 器 会 通过 比较 不 同 
选项 和 可 能 索引 的 代价 来 为 用 户 做 出 所 有 这 些 决 定 ， 因 此 无 须 为 此 感到 担忧 。 

@ 。 有效 地 使 用 位 图 扫描 

这 时 候 很 自然 地 会 出 现 一 个 问题 : 什么 时 候 一 个 位 图 扫描 最 有 用 并 且 什 么 时 候 优化 
器 才 会 选择 它 ? 在 笔者 看 来 ， 实 际 上 有 两 种 用 例 : 
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@ ”避免 反复 地 使 用 同一 个 块 。 

@ 组合 相对 不 太 好 的 条 件 。 

第 一 种 情况 相当 普遍 。 假 定 用 户 正 在 查找 讲 一 种 特定 语言 的 每 一 个 人 。 为 了 举例 方 
便 ， 假 定 所 有 人 中 有 10% 讲 所 要 求 的 语言 。 扫 描 索 引 意 味 着 表 中 的 一 个 块 必须 被 一 次 又 
一 次 地 扫描 ， 因 为 很 多 说 这 种 语言 的 人 可 能 被 存储 在 同一 块 中 。 通 过 应 用 一 个 位 图 扫 
描 ， 可 以 确保 一 个 特定 的 块 只 被 使 用 一 次 ， 这 当然 能 够 导致 更 好 的 性 能 。 

第 三 种 常见 的 用 例 是 将 相对 较 弱 的 条 件 用 在 一 起 。 让 我 们 假设 要 查找 年 龄 介 于 20 一 
30 岁 且 拥有 一 件 黄色 衬衫 的 每 一 个 人 。 现 在 ， 可 能 所 有 人 中 有 15% 介 于 20 一 30 岁 ， 并 且 
有 15% 拥 有 一 件 黄色 衬衫 。 顺 序 扫描 一 个 表 是 非常 昂贵 的 ， 因 此 PostgreSQL 可 能 会 决定 
选择 两 个 索引 ， 因 为 最 终 的 结果 可 能 只 由 1% 的 数据 构成 。 扫 描 这 两 个 索引 可 能 比 读 取 所 
有 数据 要 划算 。 


3.1.6 ”以 一 种 聪明 的 方式 使 用 索引 


到 目前 为 止 ， 应 用 一 个 索引 就 好 像 圣 杯 ， 它 总 是 能 神奇 地 提升 性 能 。 不 过 ， 并 非 总 
是 如 此 。 索 引 在 某 些 情况 下 也 会 相当 没有 意义 。 
在 更 加 深入 探究 之 前 ， 这 里 有 一 个 用 于 这 个 例子 的 数据 结构 。 记 住 只 有 两 个 不 同 的 
名 字 和 唯一 的 ID: 
test=# \d t test 
Table "public.t test" 





























Column | Type | Modifiers 

i I Ee Ee 

id | integer | not null default nextvall('t test id seq'::regclass) 
name 1 text 1 

Indexes : 


"idx id" btree (id) 
此 时 ， 已 经 有 一 个 索引 被 定义 ， 它 覆盖 了 id 列 。 在 下 一 步 中 将 查询 name 列 。 在 查询 
前 ， 将 先 在 name 上 创建 一 个 索引 : 
test=# CREATE INDEX idx name ON t test (name); 
CREATE INDEX 
现在 是 时 候 看 看 该 索引 是 否 被 正确 使 用 了 : 


test=# EXPLAIN SELECT * FROM 七 test WHERE name = "hans2"7 
QUERY PLAN 
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Index Scan using idx name on t test (cost=0.43..4.45 rows=1 width=9) 
Index Cond: (name = 'hans2'::text) 
(2 rows) 


如 我 们 所 愿 ，PostgreSQL 将 决定 使 用 该 索引 。 这 也 是 大 部 分 用 户 期 待 的 。 但 注意 笔 
者 的 查询 说 的 是 hans2。 记 住 : hans2 在 该 表 中 不 存在 ， 并 且 查 询 计划 完美 地 反映 了 这 一 
点 。rows=1 表示 计划 器 只 期 待 该 查询 返回 数据 的 一 个 非常 小 的 子 集 。 


在 表 中 一 个 行 也 没有 ， 但 是 PostgreSQL 从 不 会 估计 出 零 行 ， 因 为 那 会 
让 后 续 的 估计 变 得 困难 许多 。 


如 果 我 们 查找 更 多 数据 ， 来 看 看 会 发 生 什么 : 


test=# EXPLAIN SELECT * FROM t test WHERE name='hans' OR name="'paul'; 
QUERY PLAN 
Seq Scan on t test (cost=0.00..81622.00 rows=3000011 width=9) 
Filter: ((name = 'hans'::text) OR (name = 'paul'::text)) 
(2 rows) 


在 这 种 情况 下 ，PostgreSQL 将 使 用 一 个 直截了当 的 顺序 扫描 。 为 什么 会 这 样 ? 为 什 
么 系统 忽略 了 所 有 的 索引 ? 原因 很 简单 : hans 和 paul 组 成 了 整个 数据 集 ， 因 为 其 中 没有 
其 他 值 。 因 此 ，PostgreSQL 认为 整个 表 无 论 怎样 都 必须 被 读 取 。 如 果 只 需要 读 取 表 就 足 
够 ， 那 么 就 没有 理由 去 读 取 所 有 索引 以 及 整个 表 。 

换 句 话说 ，PostgreSQL 并 不 会 只 因为 有 一 个 索引 而 使 用 它 。PostgreSQL 会 在 索引 有 
意义 时 使 用 。 如 果 行 数 较 小 ，PostgreSQL 将 再 次 考虑 位 图 扫描 和 普通 索引 扫描 : 

test=# EXPLAIN SELECT * FROM 七 test WHERE name = 'hans2' OR name = 

"paul2"s 

QUERY PLAN 


Bitmap Heap Scan on t test (cost=8.88..12.89 rows=1 width=9) 
Recheck Cond: ((name = 'hans2'::text) OR (name = 'paul2'::text)) 
-> BitmapOr (cost=8.88..8.88 rows=1 width=0) 
-> Bitmap Index Scan on idx name (cost=0.00..4.44 rows=1 width=0) 
Index Cond: (name = 'hans2'::text) 
-> Bitmap Index Scan on idx name (cost=0.00..4.44 rows=1 width=0) 


Index Cond: (name = "paul2'::text) 


这 里 要 学 习 的 最 重要 的 一 点 是 执行 计划 取决 于 输入 值 。 它 们 不 是 静态 的 并 且 依 赖 于 
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表 中 的 数据 。 这 是 一 个 非常 重要 的 观察 ， 我 们 要 一 直 把 它 记 在 脑子 里 。 在 真实 世界 的 例 
子 中 ， 计 划 的 改变 可 能 常常 导致 不 可 预知 的 运行 时 间 。 


3.2 ”使 用 聚 簇 表 改 善 速度 


在 本 节 中 ， 读 者 将 认识 到 关联 的 力量 以 及 聚 簇 表 的 力量 。 其 关键 思想 是 什么 ”考虑 
用 户 想 要 读 取 一 整个 范围 的 数据 的 情况 。 这 个 范围 可 能 是 一 定 的 时 间 范 围 、 一 些 块 、ID 
等 。 这 种 查询 的 运行 时 间 会 根据 数据 量 以 及 数据 在 磁盘 上 的 物理 分 布 而 变化 。 因 此 ， 即 
便 用 户 运行 返回 同样 数量 行 的 查询 ， 两 个 系统 可 能 不 会 在 相同 的 时 间 跨 度 内 提供 回答 ， 
因为 物理 磁盘 布局 可 能 会 不 同 。 

这 里 有 一 个 例子 : 

test=# EXPLAIN (analyze true, buffers true, timing true) 

SELECT * 


FROM t test 
WHERE id < 10000; 




















QUERY PLAN 


Index Scan using idx id on 七 test (cost=0.43..370.87 rows=10768 
width=9) 
(actual time=0.011..2.897 rows=9999 loops=1) 
Index Cond: (id < 10000) 
Buffers: shared hit=85 
Planning time: 0.078 ms 
Execution time: 4.081 mundefined 
(5 rows) 


读者 可 能 还 记得 ， 数 据 是 以 一 种 有 组 织 的 并 且 顺 序 的 方式 被 装载 到 表 中 。 数 据 被 一 
个 ZJD 接着 一 个 ID 添加 ， 因 此 可 以 预期 这 些 数据 将 以 连续 的 顺序 放 在 磁盘 上 。 如 果 数 据 
使 用 某 个 自 增 列 被 装载 到 一 个 空 表 中 ， 情 况 就 是 如 此 。 

我 们 已 经 见 过 EXPLAIN 的 作用 ， 这 个 例子 中 利用 了 EXPLAIN (analyze true, buffers 
true, timing true)。analyze 除了 展示 查询 计划 之 外 ， 还 会 执行 该 查询 并 且 展 示 执 行 时 的 情 
况 。 对 比较 规划 器 的 估计 值 和 实际 值 来 说 ，EXPLAIN analyze 非常 好 。 要 判断 规划 器 是 正 
确 的 还 是 差 得 很 远 ， 这 是 一 种 最 好 的 方法 。buffers true 参数 将 告诉 我 们 该 查询 会 用 到 多 少 
8000 字 节 的 块 ， 在 这 个 例子 中 ， 总 共用 了 85 个 块 。shared hit 表示 来 自 于 PostgreSQL 的 
IO 缓冲 (共享 缓存 ) 的 数据 ，PostgreSQL 一 共 花 了 4 毫秒 来 检索 这 些 数据 。 

如 果 表 中 的 数据 有 点 随机 会 怎样 呢 ? 会 发 生变 化 吗 ? 要 创建 一 个 含有 同样 的 数据 但 
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顺序 随机 的 表 ， 可 以 简单 地 使 用 ORDER BY random0。 它 将 确保 数据 在 磁盘 上 确实 是 混 


乱 的 : 


test=# CREATE TABLE t random AS SELECT * FROM t test ORDER BY random(); 
SELECT 4000000 


为 了 保证 比较 公平 ， 在 同一 个 列 上 建立 索引 : 

test=# CREATE INDEX idx random ON t random (id); 

CREATE INDEX 

要 正确 工作 ，PostgreSQL 会 需要 优化 器 统计 信息 。 那 些 统计 信息 将 会 告诉 PostgreSQL 
有 多 少数 据 、 值 是 怎样 分 布 以 及 数据 在 磁盘 上 是 否 相 关 。 为 了 更 快 地 得 到 统计 信息 ， 笔 
者 在 这 里 增加 了 一 次 VACUUM 调用 。 请 注意 ， 关 于 VACUUM 稍 后 将 在 本 书 中 详细 讨论 : 

test=# VACUUM ANALYZE t random; 

VACUUM 


现在 让 我 们 运行 同样 的 查询 : 


test=# EXPLAIN (analyze true, buffers true, timing true) SELECT * FROM 
t_random WHERE id < 10000; 


QUERY PLAN 


Bitmap Heap Scan on t random 


(cost=203.27..18431.86 rows=10689 width=9) 
(actual time=5.087..13.822 rows=9999 loops=1) 


Recheck Cond: (id < 10000) 

Heap Blocks: exact=8027 

Buffers: shared hit=8057 

-> Bitmap Index Scan on idx random 


(cost=0.00..200.60 rows=10689 width=0) 
(actual time=3.558..3.558 rows=9999 loops=1) 
Index Cond: (id < 10000) 
Buffers: shared hit=30 


Planning time: 0.075 ms 

Execution time: 14.411 ms 

(9 rows) 

这 里 可 以 观察 到 很 多 事情 。 首 先 ， 需 要 的 数据 块 是 令 人 震惊 的 8057 块 ， 而 且 运 行 时 
间 也 飞涨 到 14 上 毫秒。 唯一 在 某 种 程度 上 拯救 了 性 能 的 事情 是 ， 数 据 还 是 来 自 于 内 存 而 非 
磁盘 。 想 想 如 果 不 得 不 访问 磁盘 8057 次 来 回答 这 个 查询 意味 着 什么 ， 那 将 是 一 场 彻 头 彻 


尾 的 灾难 ， 


























因为 磁盘 等 待 势必 会 让 速度 剧烈 地 慢 下 来 。 
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不 过 ， 还 可 以 看 到 更 多 ， 甚 至 可 以 看 到 计划 已 经 发 生 了 改变 。PostgreSQL 现在 使 用 


一 个 位 图 扫描 取代 了 普通 索引 扫描 。 这 被 用 来 减少 该 查询 中 所 需 的 块 数 以 防止 更 差 的 行 





规划 器 是 怎么 知道 数据 被 如 何 存储 在 磁盘 上 ? pg_stats 是 一 个 包含 了 所 有 有 关 列 内 容 





统计 信息 的 系统 视图 。 下 面 的 查询 显示 了 有 关 的 内 容 : 


的 


test=# SELECT tablename, attname， correlation FROM pg stats WHERE 
tablename IN ('t test', 't random') ORDER BY 1, 2; 
tablename | attname | correlation 


| te 
t random | id | -0.0114944 

t random | name | 0.493675 

t test | id Li 

t test | name DE 

(4 rows) 


可 以 看 到 PostgreSQL 关心 每 一 个 列 。 该 视图 的 内 容 由 一 种 叫 作 ANALYZE 的 东西 创 
它 对 性 能 至 关 重 要 : 
test=# \h ANALYZE 


Command: ANALYZE 

Description: collect statistics about a database 

Syntax: 

ANALYZE [ VERBOSE ] [ table name [ ( column name [, ...] ) ] ] 


通常 ， 会 有 一 个 所 谓 的 autovacuum 守护 进程 在 后 台 自 动 地 执行 ANALYZE， 


autovacuum 会 在 本 书 的 后 续 部 分 中 介绍 。 





回 到 查询 。 如 你 所 见 ， 两 个 表 都 有 两 列 (id 和 name)。 对 于 t_test.id， 关 联 度 是 1， 


这 表示 下 一 个 值 有 些 依赖 于 前 一 个 值 。 在 笔者 的 例子 中 ， 数 字 是 升序 的 。 同 样 的 情况 也 
适用 于 ttestname。 首 先 ， 有 一 些 项 含有 hans; 其 次 还 有 一 些 值 含有 paul。 所 有 相同 的 
名 称 因此 被 存在 一 起 。 














在 t_random 中 ， 情 况 大 相 径 庭 ， 一 个 负 的 相关 度 表 示 数 据 是 混乱 的 。 还 可 以 看 到 


name 列 的 关联 度 大 约 是 0.5， 实 际 上 ， 它 表示 在 该 表 中 相同 的 名 字 通 常 不 是 挨 在 一 起 ， 它 
还 意味 着 以 物理 顺序 读 取 该 表 时 ， 读 到 的 名 字 总 是 在 切换 。 





为 什么 这 会 导致 该 查询 命中 这 么 多 块 ? 答案 相对 比较 简单 。 如 果 我 们 需要 的 数据 并 


没有 被 紧密 地 包装 在 一 起 而 是 均匀 地 散布 在 表 中 ， 就 需要 更 多 的 块 来 提取 出 等 量 的 信 


息 ， 


进而 导致 更 糟糕 的 性 能 。 
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3.2.1 聚 簇 表 


在 PostgreSQL 中 ， 有 一 个 叫 作 CLUSTER 的 命令 ， 它 让 我 们 能 够 以 一 种 想 要 的 顺序 
重 写 一 个 表 。 可 以 指定 一 个 索引 并 且 按 该 索引 的 顺序 来 存储 数据 : 


test=# \h CLUSTER 





Command: CLUSTER 
Description: cluster a table according to an index 
Syntax: 


CLUSTER [VERBOSE] table name [ USING index name ] 

CLUSTER [VERBOSE] 

CLUSTER 命令 已 经 存在 了 很 多 年 并 且 效 果 良 好 。 但 是 ， 盲 目地 在 一 个 生产 系统 中 运 

行 它 之 前 ， 有 一 些 事 情 需要 考虑 : 

@ CLUSTER 命令 在 运行 时 将 锁 住 表 。 在 CLUSTER 运行 期 间 ， 不 能 插入 或 者 修改 
数据 。 这 对 于 生产 系统 可 能 是 无 法 接受 的 。 

@ 数据 只 能 被 按照 一 个 索引 进行 组 织 。 用 户 不 能 同时 通过 邮编 、 姓 名 、ID 、 生 日 
等 排序 同一 个 表 。 这 意味 着 如 果 存 在 一 个 大 部 分 时 间 都 会 被 使 用 的 搜索 条 件 ， 
CLUSTER 就 有 意义 。 

@ 记 住 本 书 中 给 出 的 例子 更 像 是 一 种 最 坏 的 情况 。 实 际 上 ， 一 个 聚 簇 表 和 一 个 未 
聚 徐 表 之 间 的 性 能 差异 将 取决 于 负载 、 接 收 到 的 数据 量 、 缓 存 命中 率 等 很 多 
因素 。 

@ 如果 一 个 表 在 正常 操作 时 被 更 改 ， 它 的 聚 簇 状 态 将 无 法 维持 。 随 着 时 间 的 流 
逝 ， 关 联 度 可 能 会 恶化 。 

这 里 是 一 个 如 何 运行 CLUSTER 命令 的 例子 : 


test=# CLUSTER t random USING idx random; 
CLUSTER 


上 聚 簇 所 需 的 时 间 会 根据 表 的 尺寸 而 变化 。 

3.2.2 ”使 用 只 用 索引 的 扫描 

到 目前 为 止 ， 读 者 已 经 看 到 了 何 时 会 使 用 索引 以 及 何 时 不 会 使 用 索引 。 除 此 之 外 ， 
还 讨论 了 位 图 扫描 。 

不 过 ， 索 引 还 不 止 这 些 内 容 。 下 面 的 两 个 例子 只 有 很 小 的 区 别 ， 但 是 它们 的 性 能 差 
异 可 能 会 相当 大 。 这 是 第 一 个 查询 : 
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test=# EXPLAIN SELECT * FROM t test WHERE id = 34234; 
QUERY PLAN 


Index Scan using idx id on t test 
(cost=0.43..8.45 rows=1 width=9) 
Index Cond: (id = 34234) 


这 里 看 不 出 有 什么 不 寻常 的 。PostgreSQL 使 用 一 个 索引 来 寻找 一 个 行 。 那 么 如 果 只 
选择 一 个 列 会 发 生 什么 呢 ? 
test=# EXPLAIN SELECT id FROM t test WHERE id = 34234; 


QUERY PLAN 


Index Only Scan using idx id on t test 
(cost=0.43..8.45 rows=1 width=4) 
Index Cond: (id = 34234) 

(2 rows) 


如 你 所 见 ， 计 划 已 经 从 一 个 索引 扫描 变 成 了 一 个 所 谓 的 只 用 索引 的 扫描 。 在 我 们 的 
例子 中 ，id 列 已 经 被 建立 索引 ， 因 此 它 的 内 容 很 自然 地 存在 于 该 索引 中 。 如 果 所 有 的 数 
据 已 经 可 以 从 索引 中 取出 ， 那 么 在 大 部 分 情况 下 就 没有 必要 去 表 中 取 。( 几 乎 ) 只 有 额外 
的 列 被 查询 时 ， 才 需要 去 表 中 取 数 据 ， 而 这 个 例子 并 不 属于 这 种 情况 。 因 此 ， 只 用 索引 
的 扫描 将 会 带 来 比 普通 索 引 扫描 明显 更 好 的 性 能 。 

实际 上 ， 甚 至 可 以 在 一 个 索引 中 包括 额外 列 来 享受 这 一 特性 带 来 的 好 处 。 在 MS SQL 
中 ， 增 加 额外 列 被 称 为 覆盖 索引 。PostgreSQL 也 能 实现 类 似 的 行为 。 


3.3 理解 另外 的 B- 树 特性 


在 PostgreSQL 中 ， 索 引 是 一 个 很 大 的 领域 并 且 覆 盖 了 数据 库 工 作 的 很 多 方面 。 正 如 
笔者 在 本 书 中 已 经 介绍 的 ， 索 引 是 性 能 的 关键 ， 没 有 正确 的 索引 就 不 会 有 好 的 性 能 。 因 
此 ， 那 些 与 索引 相关 的 特性 值得 更 详细 地 检阅 。 

3.3.1 组 合 索引 

在 作为 一 个 专业 PostgreSQL 支持 提供 商 的 日 子 里 ， 笔 者 常常 被 问 到 组 合 索引 和 个 体 
索引 之 间 的 区 别 。 在 本 节 中 ， 笔 者 将 尝试 型 清楚 这 个 问题 。 

一 般 的 规则 是 这 样 : 如 果 单 个 索引 就 能 回答 用 户 的 问题 ， 它 通常 就 是 最 好 的 选择 。 
不 过 ， 不 可 能 在 人 们 过 滤 的 域 的 所 有 可 能 组 合 上 建立 索引 。 我 们 所 能 做 的 就 是 使 用 组 合 
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索引 的 性 质 来 达到 尽 可 能 多 的 收益 。 
假定 有 一 个 含有 3 列 〈postal code、last name 和 first name) 的 表 。 一 个 电话 本 会 利 























用 包含 这 3 列 的 组 合 索引 。 读 者 将 会 看 到 其 中 的 数据 被 根据 位 置 排序 ， 在 同一 个 位 置 ， 





数据 将 被 按照 姓 和 名 来 排序 。 
表 3-1 展示 了 哪些 操作 可 能 用 到 给 定 的 3 列 索引 。 
表 3-1 
查 询 是 否 可 能 备 注 
postal_code = 2700 AND 
last_name ='Sch6nig' AND | 可 能 这 是 这 个 索引 最 理想 的 用 例 
first_name = 'Hans' 
postal code = 2 可 能 没有 限制 
last name 三 'Schonigy 
| 柯 甬 PostgreSQL 将 简单 地 交换 条 件 
ostal code = 2700 
二 可 能 这 就 像 在 postal_ code 上 的 一 个 索引 ， 这 个 组 合 索引 
ee 只 是 需要 磁盘 上 的 更 多 空间 
PostgreSQL 不 再 能 使 用 该 索引 的 排序 性 质 。 不 过 ， 
可 能 ， 但 是 是 一 | 在 一 些 极端 情况 (通常 是 非常 宽 的 表 ， 包 括 无 数 


first_name = 'Hans' 








种 不 同 的 用 例 


列 ) 中 ， 如 果 扫 描 整 个 索引 和 读 取 这 个 非常 宽 的 表 
代价 一 样 低 ，PostgreSQL 会 选择 扫描 整个 索引 





如 果 列 被 单独 索引 ， 用 户 最 后 看 到 的 将 很 有 可 能 是 位 图 扫描 。 当 然 ， 一 个 单一 的 定 


制 索引 会 更 好 。 


3.3.2 ”增加 函数 索引 


到 目前 为 止 ， 读 者 已 经 见 到 了 如 何 原 封 不 动 地 索引 列 的 内 容 。 但 是 ， 这 并 非 总 是 用 
此 ，PostgreSQL 人 允许 创建 函数 索引 。 基 本 思想 非常 简单 ， 索 引 并 不 直 


户 真正 想 要 的 。 因 











接 包 括 值 ， 而 是 存储 一 个 函数 的 输出 。 
下 面 的 例子 展示 了 如 何 索 引 id 列 的 余弦 值 : 
test=# CREATE INDEX idx cos ON t random (cos(iqd)); 


CREATE INDEX 
test=# ANALYZE; 


ANALYZE 
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我 们 要 做 的 仅仅 是 把 函数 放 在 索引 创建 命令 的 列 列表 中 。 当 然 ， 并 不 是 对 所 有 种 类 
的 函数 都 能 这 样 做 。 只 有 输出 不 变 的 函数 才能 被 这 样 使 用 : 
test=# SELECT age('2010-01-01 10:00:00'::timestamptz); 


age 


Oi men Masa 

(1 row) 

age 之 类 的 函数 实在 不 适合 用 作 索 引 ， 因 为 它们 的 输出 不 是 常数 。 随 着 时 间 的 流逝 ， 
age 的 输出 也 会 改变 。PostgreSQL 会 明确 地 禁止 对 给 定 的 相同 输入 可 能 改变 结果 的 函数 。 
从 这 个 方面 来 看 ， 余 弦 函 数 是 可 以 的 ， 因 为 一 个 值 的 余弦 值 在 1000 年 之 内 都 是 相同 的 。 

要 测试 这 个 索引 ， 笔 者 写 了 一 个 简单 的 查询 来 展示 : 

test=# EXPLAIN SELECT * FROM t random WHERE cos(id) = 10; 

QUERY PLAN 





Index Scan using idx cos on t random (cost=0.43..8.45 rows=1 width=9) 
Index Cond: (cos((id)::double precision) = '10'::double precision) 
(2 rows) 


如 我 们 所 愿 ， 函 数 索引 会 像 任何 其 他 索引 一 样 被 使 用 。 
3.3.3 ”减少 空间 消耗 


索引 是 好 东西 ， 它 的 主要 目的 是 尽 可 能 提高 速度 。 但 是 和 所 有 的 好 东西 一 样 ， 索 引 也 
是 有 代价 的 ， 即 空间 消耗 。 为 了 发 挥 其 魔力 ， 索 引 必 须 以 一 种 有 组 织 的 方式 存储 值 。 如 果 
用 户 的 表 含 有 一 千 万 个 整数 值 ， 属 于 该 表 的 索引 在 逻辑 上 将 会 包含 这 一 千 万 个 整数 值 。 

B- 树 还 将 包含 指向 表 中 每 一 个 行 的 指针 ， 因 此 索引 并 非 是 免费 的 。 为 了 看 到 一 个 索 
引 需要 多 少 空间 ， 可 以 使 用 vdi+ 命 令 问 问 psql: 


test=# \di+ 
List of relations 


Schema | Name | Type | Owner | Table | Size 

一 一 一 一 一 一 一 一 十 一 一 一 一 一 一 一 一 一 一 一 一 十 一 一 一 一 一 一 一 十 一 一 一 一 一 一 一 十 一 一 一 一 一 一 一 一 一 一 十 一 一 一 一 一 一 一 
public | idx cos | index | hs | t random | 86 MB 
public | idx id | index | hs test 1 86 MB 
public | idx name 1 index | hs lt test | 86 MB 
public | idx random | index | hs 1 七 random | 86 MB 


(4 rows) 
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在 笔者 的 数据 库 中 ， 存 储 那些 索引 消耗 掉 了 令 人 吃惊 的 344MB。 现 在 ， 来 与 底层 表 
烧 掉 的 存储 量 做 个 比较 : 


test=# \d+ 
List of relations 

Schema | Name | Type | Owner | Size 

一 一 一 一 一 一 一 一 十 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 十 一 一 一 一 一 一 一 一 一 一 十 一 一 一 一 一 一 一 十 一 一 一 一 一 一 一 一 一 一 一 一 
public | t random | table ee; 1 169 MB 
public | t test | table Us: 1 169 MB 
public | t test id seq | sequence | hs | 8192 bytes 
(3 rows) 


两 个 表 的 尺寸 加 起 来 也 只 不 过 是 338MB 。 换 名 话说， 我 们 的 索引 需要 比 实际 数据 更 
多 的 空间 。 在 现实 世界 中 ， 这 种 现象 很 普遍 并 且 确 实 很 容易 出 现 。 最 近 笔 者 拜访 了 一 个 
在 德国 的 Cybertec 的 客户 ， 笔 者 看 到 了 一 个 数据 库 ， 其 大 小 的 64% 都 由 从 不 使 用 在 数 
月 间 都 没有 使 用 哪怕 一 次 ) 的 索引 构成 。 因 此 ， 过 度 索 引 也 会 和 索引 不 足 一样 成 为 一 个 
问题 。 回 忆 一 下 ， 那 些 索引 不 只 是 消耗 空间 ， 每 一 个 INSERT 或 者 UPDATE 也 必须 维护 
那些 索引 中 的 值 。 在 像 我 们 的 例子 的 极端 情况 下 ， 这 会 极 大 地 降低 写 吞 吐 量 。 

如 果 在 表 中 只 有 少数 不 同 的 值 ， 部 分 索引 是 一 种 方案 

test=# DROP INDEX idx name; 

DROP INDEX 

test=# CREATE INDEX idx name ON 七 test (name) WHERE name NOT IN ('hans', 

"paul7) 7 

在 这 种 情况 下 ， 大 部 分 数据 被 排除 在 该 索引 之 外 ， 这 样 可 以 享受 到 一 个 小 的 、 高 效 
的 索引 : 


test=# \di+ idx name 





List of relations 


Schema | Name | Type | Owner | Table | Size 

一 一 一 一 一 一 一 一 十 一 一 一 一 一 一 一 一 一 一 十 一 一 一 一 一 一 一 十 一 一 一 一 一 一 一 十 一 一 一 一 一 一 一 一 十 一 一 一 一 一 一 一 一 一 一 一 
public | idx name | index | hs 1 t test | 8192 bytes 
(1 row) 


注意 只 有 排除 那些 非常 频繁 的 、 占 据 了 表 中 很 大 一 部 分 至少 25% 左 右 ) 的 值 才 有 
意义 。 部 分 索引 的 理想 候选 是 性 别 ( 我 们 假设 大 部 分 人 是 男性 或 者 女性 )、 国 籍 (假设 大 
部 分 人 都 有 相同 的 国籍 等。 当然 ， 应 用 这 类 花招 需要 对 数据 有 深入 的 认识 ， 但 它 一 定 
会 有 效果 。 
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3.3.4 在 建立 索引 时 添加 数据 


创建 一 个 索引 很 容易 。 但 是 ， 在 索引 正在 被 构建 时 不 能 修改 其 基 表 。CREATE INDEX 
命令 将 会 用 一 个 SHARE 锁 锁 住 表 来 确保 不 会 发 生 任何 更 改 。 虽 然 这 对 于 小 表 不 成 问题 ， 
但 它 将 会 在 生产 系统 的 大 型 表 上 导致 问题 。 索 引 TB 大 小 的 数据 将 会 花 一 些 时 间 并 且 因此 
会 阻塞 该 表 过 长 时 间 ， 这 就 是 一 个 问题 。 

该 问题 的 解决 方案 是 CREATE INDEX CONCURRENTLY 命令 。 这 个 命令 构建 索引 将 
会 花 掉 更 长 的 时 间 (通常 至 少 是 普通 创建 的 两 倍 )， 但 用 户 可 以 在 创建 索引 期 间 正 常 地 使 
用 该 表 。 

下 面 是 其 执行 方式 : 


test=# CREATE INDEX CONCURRENTLY idx name2 ON t test (name); 
CREATE INDEX 





注意 ， 如 果 使 用 CREATE INDEX CONCURRENTLY 命令 ，PostgreSQL 不 保证 它 会 
成 功 。 如 果 在 系统 上 运行 的 操作 出 于 某 种 原因 与 索引 创建 发 生 冲突 ， 创 建 结束 后 会 得 到 
一 个 被 标记 为 无 效 的 索引 。 








3.4 引入 操作 符 类 


到 目前 为 止 ， 我 们 的 目标 都 是 搞 清楚 应 该 索引 什么 以 及 盲目 地 在 这 个 列 或 者 列 组 上 
应 用 索引 。 其 实 ， 我们 已 经 悄然 接受 了 一 个 让 我 们 能 这 样 做 的 假设 。 迄 今 为 止 ,我 们 所 
做 的 事情 都 基于 这 样 一 个 假设 ， 即 数据 被 排序 的 顺序 比较 固定 。 事 实 上 ， 这 种 假设 可 能 
不 成 立 。 当 然 ， 数 字 将 总 是 有 相同 的 顺序 ， 但 是 其 他 种 类 的 数据 将 很 有 可 能 没有 一 种 预 
定义 的 、 固 定 的 排序 顺序 。 

为 了 证 明 这 一 观点 ， 笔 者 编制 了 一 个 现实 世界 的 例子 。 看 看 下 面 两 个 记录 : 

1118 09 08 78 

a 

现在 的 问题 是 ， 这 两 个 行 能 被 正确 地 排序 吗 ? 可 能 可 以 ， 因 为 一 个 出 现在 另 一 个 之 
前 。 但 这 是 不 对 的 ， 因 为 这 两 个 行 确实 有 一 些 隐藏 的 语义 。 读 者 在 这 里 看 到 的 是 两 个 奥 
地 利 社会 保险 号 码 。09 08 78 实际 意味 着 August 9, 1978， 而 01 05 77 实际 表示 May 1， 
1977。 前 4 个 数字 由 一 个 校 验 码 和 某 种 自 增 的 三 位 数 构 成 。 因 此 实际 上 1977 位 于 1978 之 
前 ， 我 们 可 能 要 考虑 交换 这 两 行 来 达到 想 要 的 排序 顺序 。 
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问题 是 PostgreSQL 并 不 知道 这 两 行 实际 意味 着 什么 。 如 果 一 个 列 被 标记 为 文本 ， 
PostgreSQL 将 会 应 用 标准 规则 来 排序 文本 。 如 果 该 列 被 标记 为 数字 ，PostgreSQL 将 应 用 
标准 规则 来 排序 数字 。 任 何 情况 下 它 都 不 会 使 用 前 述 的 那么 古怪 的 方式 来 排序 。 如 果 读 
者 觉得 在 处 理 那些 数字 时 只 需要 考虑 笔者 之 前 抛 出 的 事实 ， 那 就 错 了 。 一 年 有 多 少 个 
月 ? 12 个 ? 远 非 如 此 。 在 奥地利 的 社会 保险 系统 中 ， 这 些 数字 可 能 容纳 14 个 月 ? 为 什 
么 ? 回想 一 下 ， 三 位 数 仅仅 是 一 个 自 增值 。 麻 烦 在 这 里 : 如 果 一 个 移民 或 者 难民 没有 有 
效 的 文书 并 且 不 知道 他 /她 的 生日 ， 将 会 给 他 /她 分 配 一 个 虚构 的 在 第 13 个 月 的 生日 。 在 
1990 年 的 巴尔 干 战争 中 ， 奥 地 利 为 超过 115000 位 难民 提供 了 庇护 。 显 然 这 个 三 位 数 是 不 
够 的 并 且 会 增加 第 14 个 月 。 现 在 ， 哪 一 种 标准 数据 类 型 能 够 处 理 这 种 从 1970 年 年 初 
〈 这 种 社会 保险 号 码 结构 被 引入 的 时 间 ) 开始 就 存在 的 COBOL 遗留 数据 ? 答案 是 没有 。 

为 了 以 一 种 理智 的 方式 处 理 用 于 特殊 目的 的 域 ，PostgreSQL 提供 了 操作 符 类 


test=# \h CREATE OPERATOR CLASS 





























Command: CREATE OPERATOR CLASS 
Description: define a new operator class 
Syntax: 


CREATE OPERATOR CLASS name [ DEFAULT ] FOR TYPE data type 

USING index method [ FAMILY family name ] RS 

{ OPERATOR strategy number operator name [ ( op type, op type ) ] [ FOR 
SEARCH | FOR ORDER BY sort family name ] 

| FUNCTION support number [ ( op type [ , op type ] ) ] function name ( 
argument type [r=-=]) 

| STORAGE storage type 
lk 


一 个 操作 符 类 将 会 告诉 一 个 索引 应 该 怎么 运转 。 让 我 们 看 一 个 标准 的 二 叉 树 。 它 可 
以 执行 5 种 操作 ， 如 表 3-2 所 示 。 





小 于 
小 于 等 于 
等 于 
大 于 等 于 
大 于 


标准 的 操作 符 类 支持 这 本 书 中 我 们 已 经 用 过 的 标准 数据 类 型 和 标准 操作 符 。 如 果 想 


























要 处 理 社会 保险 号 码 ， 就 需要 提出 自己 的 操作 符 来 提供 所 需 的 逻辑 。 这 些 自 定义 操作 符 
接着 可 以 被 用 来 构造 一 个 操作 符 类 ， 它 其 实 就 是 一 种 传递 给 索引 的 策略 ， 它 可 以 设 定 索 
引 应 该 怎样 运作 。 

@ 为 B- 树 设计 一 种 操作 符 类 

为 了 给 出 一 个 例子 展示 一 个 操作 符 类 长 什么 样子 ， 笔 者 已 经 设计 了 一 些 代 码 来 处 理 
社会 保险 号 码 。 为 了 让 代码 更 加 简洁 ， 笔 者 没有 理会 校 验 码 之 类 的 细节 。 


1. 创建 新 操作 符 


第 一 件 事情 ， 也 是 必须 要 做 的 一 件 事情 ， 是 设计 想 要 的 操作 符 。 注 意 需要 5 种 操作 
符 。 每 一 种 策略 一 种 操作 符 。 索 引 的 策略 实际 上 像 是 一 种 插件 ， 人 允许 用 户 能 植 入 自己 的 
代码 。 

在 开始 之 前 ， 笔 者 已 经 编制 了 一 些 测试 数据 : 

CREATE TABLE t sva (sva text); 

INSERT INTO t sva VALUES ('1118090878"'); 

INSERT INTO t_ sva VALUES ('2345010477"'); 

现在 测试 数据 已 经 有 了 ， 是 时 候 创建 一 个 操作 符 了 。 为 此 ，PostgreSQL 提供 了 
CREATE OPERATOR 命令 : 


test=# \h CREATE OPERATOR 


Command: CREATE OPERATOR 
Description: define a new operator 
Syntax: 


CREATE OPERATOR name ( 
PROCEDURE = function name 
[, LEFTARG = left type ] [, RIGHTARG = right type ] 
[, COMMUTATOR = com op ] [, NEGATOR = neg op ] 
[, RESTRICT = res proc ] [, JOIN = join proc ] 
[, HASHES ] [, MERGES ] 
) 


基本 上 ， 其 中 的 概念 是 这 样 的 :一 个 操作 符 调用 一 个 函数 ， 函 数 会 得 到 一 个 或 者 两 
个 参数 ， 一 个 是 操作 符 的 左 参 数 而 另 一 个 是 操作 符 的 右 参数 。 

如 你 所 见 ， 一 个 操作 符 无 非 就 是 一 个 函数 调用 。 因 此 接 下 来 就 需要 在 那些 隐藏 在 操 
作 符 下 面 的 函数 中 实现 所 需要 的 逻辑 。 为 了 固定 排序 顺序 ， 笔 者 已 经 写 好 了 一 个 名 为 
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normalize si 的 函数 : 


CREATE OR REPLACE FUNCTION normalize si(text) RETURNS text RS $$ 
BEGIN 
RETURN substring($1, 9, 2) 11 
Substringlsl Ta oy Ml 
substring(slr Sr 2 Hl 
SubstringfSl le A)s 


END; $$ 
LANGUAGE ‘'plpgsql' IMMUTABLE; 
调用 该 函数 将 会 返回 下 面 的 结果 : 


test=# SELECT normalize si('1118090878"'); 
normalize si 


7808091118 
(1 row) 


如 上 所 示 ， 我 们 所 做 的 也 不 过 是 交换 了 一 些 数 位 ， 现 在 就 可 以 使 用 普通 的 字符 串 排 
序 顺 序 了 。 在 下 一 步 中 ， 这 个 函数 就 已 经 被 用 来 直接 比较 社会 保险 号 码 了 。 第 一 个 需要 
的 函数 是 小 于 函数 ， 它 属于 第 一 个 策略 : 
CREATE OR REPLACE FUNCTION si 1t(text，text) RETURNS boolean RS $$ 
BEGIN 


RETURN normalize si($1) < normalize si($2); 
END; 
$$ LANGUAGE 'plpgsql' IMMUTABLE; 


这 里 有 两 件 需要 注意 的 事情 : 

@ 函数 不 能 用 SQL 写 ， 只 能 用 一 种 过 程 语 言 或 者 编译 语言 来 编写 函数 。 其 原因 在 
于 SQL 函数 在 某 些 情况 下 可 能 是 内 联 的 ， 这 会 让 所 有 的 努力 前 功 尽 弃 。 

@ 应 该 坚持 本 章 中 所 使 用 的 命名 习惯 ， 这 种 习惯 被 社区 广泛 接受 。 小 于 函数 应 该 
被 称 为 lt， 小 于 等 于 函数 应 该 被 称 为 le 等 。 

有 了 这 些 知识 后 ， 就 可 以 定义 我 们 未 来 的 操作 符 所 需 的 函数 : 

-- lower equals 


CREATE OR REPLACE FUNCTION si le (text，text) RETURNS boolean RS $$ 
BEGIN 


RETURN normalize si($1) <= normalize si($2); 
END; 
$$ LANGUAGE ‘plpgsql' IMMUTABLE; 
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-- greater equal 

CREATE OR REPLACE FUNCTION si ge (text，text) RETURNS boolean RS $$ 
BEGIN 
RETURN normalize si($1) >= normalize si($2); 
END; 

$$ LANGUAGE ‘plpgsql' IMMUTABLE; 


-— greater 

CREATE OR REPLACE FUNCTION si gt(text, text) RETURNS boolean AS $$ 
BEGIN 
RETURN normalize si($1) > normalize si($2); 
END; 

$$ LANGUAGE '‘'plpgsql' IMMUTABLE; 


目前 ， 已 经 定义 了 4 个 函数 。 用 于 相等 操作 符 的 第 5 个 函数 不 是 必需 的 。 我 们 可 以 
简单 地 用 已 有 的 操作 符 ， 因 为 相等 并 不 依赖 于 排序 顺序 。 
现在 所 有 的 函数 都 就 位 了 ， 是 时 候 定义 那些 操作 符 了 : 
-- define operators 
CREATE OPERATOR <# ( PROCEDURE=si 1t, 
LEFTARG=text, 
RIGHTARG=text); 


操作 符 的 设计 其 实 非 常 简单 。 操 作 符 需要 一 个 名 字 在 笔者 的 情况 中 是 <#)、 一 个 要 
被 调用 的 过 程 ， 还 有 左右 参数 的 数据 类 型 。 当 操作 符 被 调用 时 ， 左 参数 将 是 si_lt 的 第 一 
个 参数 ， 而 右 参 数 将 是 第 二 个 参数 。 

余下 的 3 个 操作 符 遵循 相同 的 原则 : 

CREATE OPERATOR <=# ( PROCEDURE=si le, 


LEFTARG=text, 
RIGHTARG=text); 





CREATE OPERATOR >=# ( PROCEDURE=si ge, 
LEFTARG=text, 
RIGHTARG=text); 


CREATE OPERATOR ># ( PROCEDURE=si gt, 
LEFTARG=text, 
RIGHTARG=text); 


所 使 用 的 索引 类 型 还 需要 几 个 支持 函数 。 在 标准 的 B- 树 中 ， 只 需要 一 个 支持 函数 ， 
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它 被 用 来 提高 内 部 的 速度 : 
CREATE OR REPLACE FUNCTION si same (text, text) RETURNS int AS $$ 
BEGIN 
TP normalize si($1) < normalize si($2) 
THEN 
RETURN -1; 
ELSIF normalize si($1) > normalize si($2) 
THEN 
RETURN +1; 
ELSE 
RETURN 0; 
END IF; 
END; 


$$ LANGUAGE 'plpgsql' IMMUTABLE; 


如 果 第 一 个 参数 较 小 ，si_same 函数 将 会 返回 -1， 如 果 两 者 相等 返回 0; 如 果 第 一 个 
参数 较 大 则 返回 1。 在 内 部 ，_same 函数 的 工作 最 重 ， 因 此 应 该 确保 优化 其 中 的 代码 。 


2， 创建 操作 符 类 
最 后 ， 所 有 的 组 件 都 已 到 位 ， 可 以 创建 索引 所 需 的 操作 符 类 : 


CREATE OPERATOR CLASS sva special ops 
FOR TYPE text USING btree 





RS 
OPERATOR 1 3 
OPERATOR 及 <=# 
OPERATOR 3 = v 
OPERATOR 4 >=# 
OPERATOR 5 > 
FUNCTION 开 Si_same (text, text); 


CREATE OPERATOR CLASS 命令 连接 策略 和 操作 符 。“OPERATOR 1 <#” 表 示 策 略 
1 将 使 用 “<#” 操 作 符 。 最 后 ，_same 函数 被 连接 到 操作 符 类 。 

注意 该 操作 符 有 一 个 名 字 并 且 被 显 式 地 定义 为 用 于 B- 树 。 

该 操作 符 类 已 经 可 以 在 索引 创建 时 使 用 : 


CREATE INDEX idx special ON t sva (sva sva special ops); 


创建 的 索引 会 以 与 之 前 略 有 不 同 的 方式 工作 : sva sva_special ops 表示 使 用 sva_special _ 
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ops 操作 符 类 来 索引 sva 列 。 如 果 没 有 显 式 地 使 用 sva_special ops， 那 么 PostgreSQL 将 不 
会 使 用 特殊 的 排序 顺序 而 是 使 用 默认 的 操作 符 类 。 


3， 测试 自 定义 操作 符 类 


在 例子 中 ， 测 试 数据 只 有 两 行 。 因 此 ，PostgreSQL 将 不 会 使 用 索引 ， 因 为 该 表 太 小 以 
至 于 使 用 索引 的 开销 反而 会 更 大 。 但 是 为 了 在 不 装载 太 多 数据 的 情况 下 完成 测试 ， 可 以 建 
议 优化 器 把 顺序 扫描 看 得 更 加 昂贵 。 可 以 在 会 话 中 使 用 下 面 的 指令 让 操作 更 加 昂贵 : 

SET enable seqscan TO off; 

这 样 索引 就 可 以 按 预期 工作 了 : 


test=# explain SELECT * FROM t sva WHERE sva = '0000112273'; 
QUERY PLAN 


Index Only Scan using idx special on t sva (cost=0.13..8.14 rows=1 
width=32) 
Index Cond: (sva = '0000112273'::text) 
(2 rows) 


test=# SELECT * FROM t sva; 


2345010477 
1118090878 
(2 rows) 


3.5 理解 PostgreSQL 索引 类 型 


到 目前 为 止 只 讨论 了 二 叉 树 。 不 过 ， 在 很 多 情况 下 B- 树 是 不 够 的 。 为 什么 会 有 这 样 
的 情况 ? 正如 在 本 章 中 讨论 的 ，B- 树 本 质 上 是 基于 排序 的 。 使 用 B- 树 可 以 处 理 操作 符 <、 
<=、=、>= 和 >。 问 题 是 ， 并 非 所 有 的 数据 类 型 都 可 以 以 一 种 有 用 的 方式 排序 。 想 象 一 个 
多 边 形 ， 如 何 能 把 这 些 对 象 以 有 用 的 方式 排序 ?当然 ， 可 以 通过 覆盖 面积 、 周 长 等 来 排 
序 ， 但 是 这 无 法 让 用 户 使 用 几何 搜索 真正 找到 它们 。 

这 个 问题 的 解决 方案 就 是 提供 更 多 的 索引 类 型 。 每 一 种 索引 将 服务 于 一 种 特殊 的 目的 
并 且 完 成 所 需要 的 工作 。PostgreSQL 中 有 下 列 索引 类 型 可 用 〈 从 PostgreSQL 9.6 开始 ): 


test=# SELECT * FROM pg am; 




















amname | amhandler | amtype 
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到 本 二 二 本 二 于 要 人 
btree | bthandler i 

hash | hashhandler | i 

GisT | GisThandler | i 

gin | ginhandler | i 
spGiST | spghandler | i 

brin | brinhandler | i 

(6 rows) 


总 共有 6 种 类 型 的 索引 。B- 树 已 经 被 详细 讨论 过 ， 但 其 他 几 种 索引 类 型 适合 什么 ? 
下 面 的 小 节 将 会 介绍 PostgreSQL 中 可 用 的 每 一 种 索引 类 型 的 目的 。 

注意 还 有 一 些 扩展 可 以 被 用 在 这 里 的 索引 类 型 之 上 。 在 网 上 还 有 一 些 额 外 的 索引 类 
型 可 用 ， 如 rum、vodka 和 未 来 的 cognac。 


3.5.1 Hash 索引 
Hash 索引 已 经 存在 了 很 多 年 。 其 思想 是 把 输入 值 进行 哈 希 并 且 将 结果 存 起 来 用 于 后 
面 的 查找 。 使 用 Hash 索引 的 确 是 有 意义 的 。 不 过 ， 在 PostgreSQL 中 并 不 建议 使 用 它们 。 


原因 是 Hash 索引 在 并 发 情况 表现 不 好 ， 并 且 不 支持 PostgreSQL 事务 日 志 。 简 而 言 之 ， 在 
可 以 预见 的 未 来 都 不 应 该 在 现实 世界 的 系统 中 使 用 它们 。 


3.5.2 ”GiST 索引 





通用 搜索 树 〈GiST) 索引 是 一 种 非常 重要 的 索引 类 型 ， 因 为 它们 应 用 于 很 多 不 同 的 
东西 。GiST 索引 可 以 被 用 来 实现 R- 树 行为 ， 它 甚至 也 可 以 作为 B- 树 来 用 。 不 过 ， 不 推荐 
把 GiST 滥用 为 B- 树 索引 。 

GiST 的 典型 用 例 有 : 

@ ”几何 索引 (例如 ， 用 于 非常 流行 的 PostGIS 扩展 ) 。 

@ 模糊 搜索 。 


1， 理解 GiST 如 何 工作 


对 于 很 多 人 来 说 ，GiST 仍然 是 一 个 黑 盒 子 。 因 此 ， 笔 者 决定 增加 一 节 来 描述 GiST 
的 内 部 是 如 何 工作 的 。 
考虑 图 3.1: 
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来 源 : http://leopard.in.ua/assets/images/postgresql/pg_indexes/pg_indexes2.jpg 

看 看 这 一 棵 树 ， 读 者 将 看 到 R1 和 R2 在 顶部 。R1 和 R2 是 包含 所 有 其 他 东西 的 外 包 

盒 。R3、R4 和 R5 被 Rl 所 包含 。R8、R9 和 R10 被 R3 所 包含 等 。 因 此 一 个 GiST 索 引 是 
层次 化 组 织 的 。 读 者 在 图 3.1 中 看 到 的 是 某 些 在 内 建 B- 树 中 没有 的 操作 。 那 些 操作 是 重 


























年、 在 左边 、 在 右边 等 。 一 棵 GiST 树 的 布局 对 于 几何 索引 非常 理想 。 
2， 扩展 GiST 
然 ， 也 可 以 设计 用 户 自己 的 操作 符 类 。 支 持 下 列 策略 ， 如 表 3-3 所 示 。 
表 3-3 


眶 














操 
Strictly left of 


Does not extend to right of 


作 
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操 作 策 略 号 
Does not extend to left of 4 
Strictly right of 3 
Same 6 
Contains 7 
Contained by 8 
Does not extend above 9 
Strictly below 10 
Strictly above 11 
Does not extend below 12 





如 果 想 要 为 GiST 编写 操作 符 类 ， 就 必须 提供 一 些 支 持 函数 。 在 B- 树 的 情况 下 ， 只 需 
要 一 个 same 函数 ， 而 GiST 索引 提供 更 多 函数 ， 如 表 3-4 所 示 。 














表 3-4 
函数 描述 支持 函数 编号 
consistent “| 该 函数 判断 一 个 键 是 否 满足 查询 限定 词 。 在 内 部 会 查找 并 检查 策略 
计算 一 个 键 集合 的 联合 。 在 数字 值 的 情况 下 ， 就 是 计算 较 高 和 较 低 的 
Wion | 值 或 者 一 个 范围 。 它 对 于 几何 结构 尤其 重要 
compress 计算 一 个 键 或 者 值 的 压缩 表示 3 
decompress | 这 是 compress 函数 的 逆 函 数 4 
在 插入 过 程 中 ， 插 入 到 树 中 的 代价 将 被 计算 出 来 。 这 个 代价 决定 新 的 
penalty 项 会 被 放 在 树 中 的 什么 位 置 。 因 此 ， 一 个 好 的 penalty 函数 是 索引 总 体 5 
性 能 好 坏 的 关键 
判断 在 页 面 分 型 时 从 哪里 开始 移动 项 。 一 些 项 必须 留 在 旧 页 面 中 ， 而 
picksplit 其 他 项 将 会 去 到 被 创建 的 新 页 面 中 。 一 个 好 的 picksplit 函数 是 好 的 索 6 
引 性 能 的 根本 
equal equal 函数 类 似 于 已 经 在 B- 树 中 见 过 的 same 函数 党 
Se 计算 一 个 键 和 查询 值 之 间 的 距离 (一 个 数字 ) 。distance 函数 是 可 选 8 
的 ， 只 有 在 支持 KNN 搜索 时 才 需 要 
ee 判断 一 个 压缩 键 的 原始 表示 。 PostgreSQL 近期 版 本 支持 的 只 用 索引 扫 了 
描 需要 用 这 个 函数 来 处 理 
GiST 索引 的 操作 符 类 通常 都 用 C 来 实现 。 如 果 想 找 一 个 好 例子 ， 建 议 去 源 代码 的 





contrib 目录 中 看 一 看 btree_GiST 模块 。 它 展示 了 如 何 使 用 GiST 索引 标准 数据 类 型 ， 并 且 
是 一 个 好 的 灵感 来 源 。 
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3.5.3 GIN 索引 


通用 倒 排 (GIN) 索引 是 一 种 好 的 索引 文本 的 方式 。 假 定 用 户 要 索引 一 百 万 个 文本 
文档 ， 一 个 特定 的 词 可 能 会 出 现 几 百 万 次 。 在 一 棵 普通 的 B- 树 中 ， 这 意味 着 键 会 被 存储 
几 百 万 次 。 但 在 GIN 索引 中 不 是 这 样 。 每 一 个 键 〈 或 者 词 ) 只 被 存储 一 次 并 且 会 被 附加 
一 个 文档 列表 。 键 以 一 棵 标准 的 B- 树 组 织 。 每 一 个 项 将 有 一 个 文档 列表 ， 它 指向 表 中 具 


有 这 个 相同 键 的 所 有 项 。 一 个 GIN 索引 会 非常 小 并 且 紧 凑 。 不 过 ， 它 缺少 B- 树 中 一 种 习 
要 的 特性 一 一 排序 数据 。 在 GIN 中 ， 与 一 个 特定 键 相 关 的 项 指针 列表 会 按照 行 在 表 中 


Wm 





人 


位 置 而 排序 ， 而 不 能 采用 一 种 随意 的 规则 。 
@ 扩展 GIN 
就 和 任何 其 他 索引 一 样 ，GIN 可 以 被 扩展 。 有 下 列 策略 可 用 ， 如 表 3-5 所 示 。 


表 3-5 


Overlap 


Contains 














在 此 之 上 ， 有 下 列 支 持 函 数 可 用 ， 如 表 3-6 所 示 。 
表 3-6 
函数 描 述 支持 函数 编号 
compare 函数 类 似 于 已 经 在 B- 树 中 见 过 的 same 函数 。 如 果 两 个 键 
I 被 比较 ， 它 会 返回 ，-1 (小 于 ) 、0 (等 于 ) 或 者 1 (大 于 ) 
二 从 一 个 要 被 索引 的 之 中 抽取 键 。 一 个 值 可 能 有 很 多 键 。 例 如 ， 一 个 本 
文本 值 可 以 由 多 于 一 个 词组 成 
extractQuery 从 一 个 查询 条 件 中 抽取 键 3 
consistent 检查 一 个 值 是 否 匹 配 一 个 查询 条 件 4 
比较 一 个 来 自 查询 的 部 分 键 和 一 个 来 自 索引 的 键 。 返 回 -1、0 或 者 
SompareParial | 1 (类 似 于 B- 树 支持 的 same 函 数 ) 
_ . 判断 一 个 值 是 否 匹 配 一 个 查询 条 件 (三 元 变 体 ) 。 如 果 consistent 
triConsistent 6 





函数 存在 ，triConsistent 就 是 可 选 的 





如 果 想 要 一 个 如 何 扩展 GIN 的 例子 ， 考 虑 看 看 在 PostgreSQL 源 代码 contrib 目录 中 的 
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btree_gin 模块 。 它 是 一 个 有 价值 的 信息 源 ， 也 是 一 种 开始 自 定义 实现 的 好 方法 。 
如 果 读 者 对 全 文 搜索 感 兴趣 ， 本 章 稍 后 还 将 提供 更 多 信息 。 


3.5.4 _ SP-GiST 索引 


空间 划分 GiST (SP-GiST) 主要 被 设计 为 在 内 存 中 使 用 。 其 原因 是 一 个 存储 在 磁盘 
上 的 SP-GiST 需要 相当 高 的 磁盘 命中 才能 工作 。 磁 盘 命 中 是 比 只 在 RAM 沿 着 一 些 指 针 查 
找 更 加 昂贵 的 方式 。 

美妙 的 事情 是 SP-GiST 可 以 被 用 来 实现 多 种 类 型 的 树 ， 例 如 四 叉 树 、k-d 树 和 radix 树 。 

SP-GiST 提供 了 表 3-7 所 示 的 策略 。 








表 3-7 
操 作 策 略 号 

Strictly left of 1 

Strictly right of 5 

Same 6 

Contained b 8 

Strictly below 10 

Strictly above 11 

要 为 SP-GiST 编写 自己 的 操作 符 类 ， 必 须 提供 如 表 3-8 所 示 的 一 些 函 数 。 

表 3-8 










提供 使 用 的 操作 符 类 的 信息 
确定 如 何 把 一 个 新 值 插 入 一 个 内 部 元 组 中 
确定 如 何 划分 /分 裂 一 组 值 
inner_consistent 判断 对 于 一 个 查询 需要 搜索 哪些 子 分 区 
leaf consistent 判断 键 是 否 满足 查询 限定 词 


3.5.5 ”BRIN 索引 





config 








choose 








picksplit 












块 范围 索引 (BRIN) 有 很 多 实际 用 途 。 到 目前 为 止 ， 讨 论 过 的 所 有 索引 都 需要 很 多 
磁盘 空间 。 尽 管 在 缩小 GIN 等 索引 方面 已 经 做 了 很 多 工作 ， 但 它们 仍然 需要 很 大 的 空 
间 ， 因 为 每 一 个 项 都 需要 一 个 索引 指针 。 因 此 如 果 有 一 千 万 个 项 ， 就 需要 有 一 千 万 个 索 
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引 指针 。 空 间 是 BRIN 索引 主要 关心 的 问题 。BRIN 索引 并 不 为 每 一 个 元 组 保存 一 个 索引 
项 ， 而 是 存储 数据 的 128 (默认 ) 个 块 (1MB) 中 的 最 小 和 最 大 值 。 因 此 这 种 索引 很 小 ， 
但 是 一 种 有 损 索 引 。 扫 描 这 种 索引 将 会 返回 比 要 求 的 更 多 的 数据 。PostgreSQL 必须 在 后 
续 的 步骤 中 过 滤 掉 那些 额外 的 行 。 

下 面 的 例子 展示 了 一 个 BRIN 索引 到 底 有 多 小 

test=# CREATE INDEX idx brin ON t test USING brin(id) 

CREATE INDEX 

test=# \di+ idx brin 

List of relations 


Schema | Name | Type | Owner | Table | Size 

一 -一 -一 一 一 一 十 一 一 一 一 一 一 一 一 一 一 十 一 一 一 一 一 一 一 十 一 一 一 一 一 一 一 十 一 一 一 一 一 一 一 一 十 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 
public | idx brin | index | hs 1 七 test | 48 KB 

(1 row) 


在 笔者 的 例子 中 ，BRIN 索引 比 一 个 标准 的 B- 树 小 2000 倍 。 但 问题 自然 就 产生 了 : 
为 什么 我 们 不 总 是 使 用 BRIN 索引 呢 ? 要 回答 这 一 类 问题 ， 了 解 BRIN 的 布局 很 重要 ， 在 
BRIN 中 存储 了 1MB 数据 的 最 小 值 和 最 大 值 。 如 果 数 据 是 排序 的 (关联 度 高 )，BRIN 是 
相当 有 效 的 ， 因 为 我 们 可 以 取出 1MB 数据 并 扫描 它 即 可 。 但 是 ， 如 果 数 据 是 乱 的 会 怎 
样 ? 在 这 种 情况 下 ，BRIN 将 无 法 排除 数据 块 ， 因 为 很 可 能 有 接近 于 总 体 最 高 值 和 最 低 值 
的 数据 在 这 1MB 中 。 因 此 ，BRIN 更 多 的 是 用 于 高 关联 的 数据 。 实 际 上 ， 在 数据 仓库 应 
用 中 高 度 关联 的 数据 是 很 有 可 能 的 。 例 如 ， 通 常 每 天 装载 数据 ， 所 以 日 期 可 能 会 高 度 
关联 。 

@ 扩展 BRIN 索引 

BRIN 支持 和 B- 树 相同 的 策略 ， 因 此 它 需 要 相同 的 操作 符 集合 。 代 码 可 以 很 好 地 被 重 
用 ， 如 表 3-9 所 示 。 





出 


表 3-9 
操作 


Less than 


遇 








Less than or equal 


Equal 





Greater than or equal 


| | I | 一 | 村 


Greater than 


BRIN 所 需 的 支持 函数 如 表 3-10 所 示 。 
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表 3-10 











函数 描述 
opcInfo | ”提供 关于 被 索引 列 的 内 部 信息 
add_ value | ”向 一 个 现 有 的 摘要 元 组 增加 一 项 
检查 一 个 值 是 否 匹 配 一 个 条 件 


union 
3.5.6 ”增加 额外 索引 
从 PostgreSQL 9.6 开始 ， 有 一 种 容易 的 方式 以 扩展 的 形式 发 布 全 新 的 索引 类 型 。 因 为 


如 果 PostgreSQL 提供 的 那些 索引 类 型 不 够 用 ， 就 可 以 增加 几 种 额外 的 索引 类 型 来 准确 地 
实现 用 户 的 目的 。 增 加 索引 类 型 的 指令 是 CREATE ACCESS METHOD: 


test=# \h CREATE ACCESS METHOD 


支持 函数 编号 



















1 
;4 
3 
4 





consistent 








Command: CREATE ACCESS METHOD 
Description: define a new access method 
Syntax: 


CREATE ACCESS METHOD name 
TYPE access method type 
HANDLER handler function 
不 用 太 担心 这 个 命令 一 一 万 一 用 户 要 部 署 自己 的 索引 类 型 ， 它 会 以 现成 的 扩展 形式 
出 现 。 
其 中 一 个 扩展 实现 了 布 隆 过 滤器 。 布 隆 过 滤器 是 概率 数据 结构 ， 它 们 有 时 会 返回 过 
多 的 行 ， 但 是 从 不 会 返回 过 少 的 行 。 因 此 ， 布 隆 过 滤器 是 一 种 预先 过 滤 数 据 的 好 方法 。 
布 隆 过 滤器 是 怎样 工作 的 呢 ? 一 个 布 隆 过 滤器 被 定义 在 几 个 列 上 。 基 于 输入 值 会 计 
算出 一 个 位 掩 码 ， 位 掩 码 会 接着 与 查询 进行 比较 。 布 隆 过 滤器 的 优势 是 可 以 想 索 引 多 少 
列 就 索引 多 少 列 。 而 其 劣势 是 整个 布 隆 过 滤器 都 必须 被 读 取 。 当 然 ， 布 隆 过 滤器 比 其 底 
层 的 数据 要 小 很 多 ， 因 此 在 很 多 情况 下 还 是 很 划算 的 。 
要 使 用 布 隆 过 滤器 ， 只 需要 激活 该 扩展 ， 它 本 身 就 是 PostgreSQL 的 contrib 包 的 一 
部 分 : 


test=# CREATE EXTENSION bloom; 
CREATE EXTENSION 


如 前 所 述 ， 布 隆 过 滤器 背后 的 思想 是 允许 索引 需要 的 任意 多 列 。 在 很 多 实际 应 用 
中 ， 挑 战 在 于 索引 很 多 列 却 不 知道 用 户 在 运行 时 真正 需要 哪些 组 合 。 在 一 个 大 型 表 的 情 
况 下 ， 完 全 不 可 能 在 80 个 或 者 更 多 个 域 上 创建 一 个 标准 的 B- 树 索引 。 这 时 候 布 隆 过 滤器 

















第 3 章 使 用 索引 “65。 


可 能 是 另 一 种 选择 : 
test=# CREATE TABLE 七 bloom (xl int, x2 int, x3 int, x4 int, x5 int, x6 
nt x int) 
CREATE TABLE 
创建 索引 很 容易 : 


test=# CREATE INDEX idx bloom ON t bloom (xl, x2, x3, x4, x5, x6, x7); 
CREATE INDEX 


如 果 关 闭 顺序 扫描 ， 该 索引 就 可 以 发 挥 作 用 : 


test=# explain SELECT * FROM 七 bloom WHERE x5 = 9 AND x3 = 77 
QUERY PLAN 


Bitmap Heap Scan on 七 bloom (cost=18.50..22.52 rows=1 width=28) 
Recheck Cond: ((x3 = 7) AND (x5 = 9)) 
-> Bitmap Index Scan on idx bloom (cost=0.00..18.50 rows=1 width=0) 
Index Cond: ((x3 = 7) AND (x5 = 9)) 
注意 笔者 查询 的 是 随机 的 几 个 列 的 组 合 ， 它 们 和 索引 中 的 实际 顺序 无 关 。 布 隆 过 滤 
器 仍 能 有 所 帮助 。 
如 果 对 布 隆 过 滤器 感 兴 趣 ， 可 以 参考 网 站 : https://en.wikipedia.org/wiki/Bloom filter。 


3.6 ”用 模糊 搜索 实现 更 好 的 回答 








当今 的 用 户 并 不 是 只 需要 执行 精确 搜索 。 现 代 的 网 站 已 经 让 用 户 习 惯 了 总 是 能 够 得 
到 一 个 结果 ， 而 不 管用 户 输入 什么 。 如 果 在 Google 上 搜索 ， 即 便 用 户 的 输入 是 错误 的 、 
背 字 连篇 或 者 毫 无 意义 ， 总 是 会 有 一 个 回答 。 人 们 总 是 期 待 好 的 结果 而 不 管 输入 数据 是 怎 
样 的 。 


3.6.1 利用 pg_trgm 


要 用 PostgreSQL 作 模 糊 搜索 ， 可 以 加 入 pg_trgm 扩展 。 要 激活 该 扩展 ， 只 需要 运行 
下 面 的 指令 : 


test=# CREATE EXTENSION pg trgm; 
CREATE EXTENSION 


pg_trgem 扩展 相当 强大 ， 为 了 展示 它 的 能 力 ， 笔 者 已 经 编 好 了 一 些 由 奥地利 2354 个 
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村 庄 和 城市 的 名 字 构 成 的 示例 数据 。 
我 们 的 示例 数据 可 以 存储 在 一 张 简单 表 中 : 


test=# CREATE TABLE t location (name text); 
CREATE TABLE 


笔者 的 公司 网 站 有 全 部 的 数据 ，PostgreSQL 可 以 直接 装载 该 数据 : 


test=# COPY t location FROM PROGRAM 'curl www.cybertec.at/secret/orte.txt'; 
COPY 2354 


€9 注意 必须 安装 curl ( 一 种 获取 数据 的 命令 行 工具 )。 如 果 没 有 这 个 工 
有 具 ， 请 正常 下 载 该 文件 ， 并 从 本 地 文件 系统 中 导入 它 。 
一 旦 数据 被 装载 完 ， 就 可 以 查询 该 表 的 内 容 : 


test=# SELECT * FROM t location LIMIT 4; 
name 





Eisenstadt 

Rust 

Breitenbrunn am Neusiedler See 
Donnerskirchen 

(4 rows) 


如 果 德语 不 是 你 的 母语 ， 就 不 太 可 能 拼写 那些 位 置 的 名 称 而 不 出 现 严 重 的 错误 。 幸 
运 地 是 ，pg_trem 可 以 帮助 你 : 


test=# CREATE EXTENSION pg_ trgm; 
CREATE EXTENSION 


pg_trgm 为 我 们 提供 了 一 种 距离 操作 符 ， 它 能 计算 两 个 字符 串 之 间 的 距离 : 


test=# SELECT ‘abcde' <-> "abdeacb' 
?column? 














0.833333 

(1 row) 

这 种 距离 是 0 和 1 之 间 的 一 个 数字 。 数 字 越 小 ， 两 个 字符 串 就 越 相似 。 

那 是 怎样 做 到 的 呢 ? trigram 会 拿 到 一 个 字符 串 并 且 把 它 解剖 成 三 字母 序列 : 


test=# SELECT show trgm('"abcdef') 
show_trgm 
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tt a ” ab”rabc,bedrcderdef. "ef ™} 
(1 row) 


这 些 序列 接着 将 被 用 来 算出 刚才 看 到 的 距离 。 当 然 ， 这 个 距离 操作 符 可 以 被 用 在 一 
个 查询 内 来 寻找 最 接近 的 匹配 : 


test=# SELECT * FROM t location ORDER BY name <-> 'Kramertneusiedel’' LIMIT 


Gramatneusiedl 
Klein-Neusiedl 
Potzneusiedl 
(3 rows) 


Gramatneusiedl 与 Kramertneusiedel 相当 接近 。 两 者 听 起 来 很 相似 并 且 使 用 一 个 K 来 
代替 G 是 一 种 很 常见 的 错误 。 在 Google 上 ， 有 时 会 看 到 Did you mean...。 这 很 可 能 就 是 
Google 在 使 用 n-gram。 

PostgreSQL 可 以 用 GiST 在 文本 上 通过 trigram 建立 索引 : 

test=# CREATE INDEX idx trgm ON t location USING GiST (name GiST trgm ops); 

CREATE INDEX 

pg_trgm 为 我 们 提供 了 GiST_trgm_ops 操作 符 类 来 做 相似 性 匹配 。 下 面 的 列表 展示 了 
该 索引 可 以 发 挥 预期 的 作用 : 

test=# explain SELECT * FROM t location ORDER BY name <-> 


'Kramertneusiedel' LIMIT 5; 
QUERY PLAN 


Limit (cost=0.14..0.58 rows=5 width=17) 
-> Index Scan using idx trgm on t location 
(cost=0.14..207.22 rows=2354 width=17) 
Order By: (name <-> 'Kramertneusiedel'::text) 
(3 rows) 


3.6.2” 加速 LIKE 查询 


LIKE 查询 肯定 会 导致 一 些 当 今 用户 所 见 过 的 最 糟糕 的 性 能 问题 。 在 大 部 分 数据 库 系 
统 中 ，LIKE 的 速度 相当 慢 并 且 要 求 一 次 顺序 扫描 。 除 此 之 外 ， 最 终 用 户 很 快 会 发 现 一 个 
模糊 搜索 大 部 分 情况 下 将 返回 比 精确 查询 更 好 的 结果 。 因 此 ， 如 果 足 够 频繁 地 在 一 个 大 
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型 表 上 调用 一 种 单一 类 型 的 LIKE 查询 ， 常 常会 前 弱 整 个 数据 库 服务 器 的 性 能 。 
幸运 地 是 ，PostgreSQL 为 这 一 问题 提供 了 解决 方案 ， 并 且 该 解决 方案 正好 已 经 被 安装 : 
test=# explain SELECT * FROM t location WHERE name LIKE '%neusi$%'; 


QUERY PLAN 





Bitmap Heap Scan on t location 
(cost=4.33..19.05 rows=24 width=13) 
Recheck Cond: (name ~~ "sneusis'" : :text) 
-> Bitmap Index Scan on idx trgm (cost=0.00..4.32 rows=24 width=0) 
Index Cond: (name ~~ 'g%neusigs'::text) 
(4 rows) 


3.6.1 节 中 部 署 的 trigram 索引 也 适合 于 加 速 LIKE 查询 。 注 意 % 符 号 可 以 被 用 在 搜索 
串 中 的 任意 位 置 。 这 是 相对 于 标准 B- 树 的 一 个 主要 优势 ， 标 准 B- 树 只 能 加 速 通配符 在 查 
询 末 端的 情况 。 


3.6.3 ”处 理 正 则 表达 式 


不 过 ， 这 还 不 是 trigram 的 全 部 作用 。trigram 索引 甚至 能 够 加 速 简单 的 正则 表达 式 。 
下 面 的 例子 展示 了 这 种 功效 : 
test=# SELECT * FROM t location WHERE name ~ '[A-C].*neu.*'; 
name 


Bruckneudorf 
(1 row) 


test=# explain SELECT * FROM t location WHERE name ~ '[A-C].*neu.*'; 
QUERY PLAN 


Index Scan using idx trgm on t location (cost=0.14..8.16 
rows=1 width=13) 
Index Cond: (name ~ '[A-C] .*neu.*'::text) 

(2 rows) 


PostgreSQL 将 检查 该 正则 表达 式 并 且 使 用 该 索引 来 回答 问题 。 


és 在 内 部 ，PostgreSQL 可 以 把 该 正则 表达 式 转 换 成 一 个 图 并 且 相 应 地 遍 
历 该 索引 。 
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3.7 理解 全 文 搜 索 -FTS 


如 果 正 在 查找 名 称 或 者 简单 的 字符 串 ， 用 户 通常 需要 查询 一 个 域 的 整个 内 容 。 在 
FTS 中 不 是 这 样 。 全 文 搜索 的 目的 是 在 一 个 文本 中 查找 词 或 者 词组 。 因 此 ，FTS 更 大 程度 
上 是 一 种 包含 操作 ， 因 为 基本 上 不 会 用 它 来 查找 一 个 准确 的 字符 串 。 

在 PostgreSQL 中 ， 可 以 使 用 GIN 索引 来 做 FTS。 其 思想 是 解剖 一 个 文本 ， 抽 出 有 价值 
的 词 位 并 且 索 引 这 些 元 素 而 不 是 底层 的 文本 。 为 了 让 搜索 更 加 成 功 ， 那 些 词 会 被 预 处 理 。 

这 里 是 一 个 例子 : 

test=# SELECT to tsvector('english', 'A car, I want a car. I would not even 

mind having many cars'); 








to tsvector 


va p(n ne cee pal) nilo ole) mien a Ozma oitns 

(1 row) 

这 个 例子 展示 了 一 个 简单 的 句子 。to_tsvector 函数 将 获取 该 字符 串 ， 应 用 英语 规则 并 
且 执 行 一 个 词 干 提取 处 理 。 基 于 配置 (english)，PostgreSQL 将 解析 该 字符 串 ， 丢 掉 停 用 
词 并 且 提取 单词 的 词 干 。 例 如 ，car 和 cars 将 被 转换 成 car。 注 意 这 与 查找 词 干 无 关 。 对 于 
many，PostgreSQL 将 简单 地 通过 应 用 英语 语言 中 工作 得 很 好 的 标准 规则 把 该 字符 串 转换 
成 mani。 

注意 ，to_tsvector 函数 的 输出 是 与 语言 高 度 相关 的 。 如 果 告 诉 PostgreSQL 把 字符 串 
当 作 Dutch 对 待 ， 结 果 将 完全 不 同 : 

test=# SELECT to tsvector('dutch', 'A car, I want a car. I would not even 


mind having many cars'); 
to tsvector 





a ear ola overn lo having lo 3 many 3 
rmind"sll not would"=8 


(1 row) 

要 搞 明白 支持 哪些 配置 ， 考 虑 运行 下 面 的 查询 : 

SELECT cfgname FROM pg ts config; 

3.7.1 比较 字符 串 

在 简单 地 看 过 了 词 干 提取 处 理 之 后 ， 让 我 们 看 看 怎样 把 经 过 词 干 提取 处 理 的 文本 与 
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一 个 用 户 查 询 相 比较 。 下 面 的 代码 片段 会 检查 wanted: 


test=# SELECT to tsvector('english', 'A car, I want a car. I would not even 
mind having many cars') @@ to tsquery('english', 'wanted'); 
?column? 


(1 row) 





注意 ，wanted 实际 上 并 未 出 现在 原始 文本 中 。 但 是 PostgreSQL 仍然 返回 真 。 原 因 是 
want 和 wanted 都 被 转换 成 相同 的 词 位 ， 因 此 结果 是 真 。 实 际 上 ， 这 是 很 有 意义 的 。 想 象 
一 下 用 户 正在 Google 上 查找 car。 如 果 能 找到 售卖 cars 的 页 面 ， 这 是 相当 不 错 的 。 因 此 
查找 公共 词 位 是 一 种 聪明 的 想法 。 

有 时 候 ， 人 们 不 只 是 查找 单一 的 词 而 是 想 找 到 一 组 词 。 如 下 一 个 例子 所 示 ， 
to_tsquery 可 以 做 到 这 一 点 : 











test=# SELECT to tsvector('english', 'A car, I want a car. I would not even 
mind having many cars') @@ to tsquery('english', "wanted & bmw'); 
?column? 


(1 row) 


这 种 情况 会 返回 假 ， 因 为 在 输入 字符 串 中 找 不 到 bmw。 在 to_tsquery 函数 中 ,，“&” 
表示 与 而 “|” 表 示 或 。 因 此 我 们 可 以 轻易 地 构建 复杂 的 搜索 串 。 


3.7.2 定义 GIN 索引 


如 果 想 在 一 列 或 者 一 组 列 上 应 用 文本 搜索 ， 基 本 上 有 两 种 选择 : 

@ ”创建 一 个 使 用 GIN 的 函数 索引 。 

@ ”增加 一 个 类 型 为 tsvector 的 列 和 一 个 触发 器 来 保持 文本 列 和 tsvector 列 同步 。 

在 本 节 中 ， 两 种 选项 都 会 被 介绍 。 为 了 展示 如 何 使 用 这 些 选项 ， 笔 者 创建 了 一 些 示 
例 数据 : 


test=# CREATE TABLE t fts AS SELECT comment FROM pg available extensions; 
SELECT 43 


直接 在 列 上 建立 函数 索引 肯定 是 一 种 较 慢 但 是 空间 效率 更 高 的 方法 : 


test=# CREATE INDEX idx fts func ON t fts USING gin (to tsvector('english', 
comment)); 
CREATE INDEX 
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在 函数 上 部 署 一 个 索引 很 容易 ， 但 是 可 能 会 带 来 一 些 负 荷 。 增 加 一 个 物化 列 需要 更 
多 空间 ， 但 是 会 得 到 更 好 的 运行 时 行为 : 

test=# ALTER TABLE t fts ADD COLUMN ts tsvector; 

ALTER TABLE 

唯一 的 麻烦 是 : 如 何 保持 这 个 列 同 步 ? 答案 是 用 一 个 触发 器 : 

test=# CREATE TRIGGER tsvectorupdate 

BEFORE INSERT OR UPDATE ON t fts 

FOR EACH ROW 

EXECUTE PROCEDURE 

tsvector update trigger(somename, 'pg_catalog.english', "comment"); 

幸运 的 是 ，PostgreSQL 已 经 提供 了 一 个 可 以 被 用 作 触 发 器 来 同步 tsvector 列 的 C 函 
数 。 只 需要 向 该 函数 传 入 一 个 名 称 、 想 要 的 语言 以 及 一 组 列 就 可 以 了 。 该 触发 器 函数 将 
做 好 一 切 所 需要 的 工作 。 注 意 一 个 触发 器 将 总 是 和 造成 修改 的 语句 处 于 同一 个 事务 中 ， 
因此 不 会 有 造成 不 一 致 的 风险 。 


3.7.3 调试 用 户 的 搜索 


有 时 并 不 太 清 楚 为 什么 一 个 查询 能 匹配 一 个 给 定 的 搜索 串 。 为 了 调试 查询 ， 
PostgreSQL 提供 了 ts_debug 函数 。 从 用 户 的 角度 来 看 ， 它 可 以 像 to_tsvector 一 样 使 用 。 
它 透露 了 很 多 有 关 FTS 内 部 工作 的 信息 : 

test=# \x 

Expanded display is on. 


test=# SELECT * FROM ts debug('english', "go to 
Www.postgresql-support .de'); 


=[ FRIED 1 |==-=-======================= 
alias | asciiword 

description | Word, all ASCII 

token Uae 

dictionaries | {english stem} 

dictionary | english stem 

lexemes 1 {go} 

RECORDE2N 
alias | blank 

description | Space symbols 

token 1 


dictionaries | {} 


。7T2 。 


dictionary 1 
lexemes 
—[ RECORD 3 ]+ 
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alias | asciiword 
description Word, all RSCII 
token to 
dictionaries {english stem} 
dictionary english stem 
lexemes Lh 


-[ RECORD 4 ]+ 
alias 
description 
token 
dictionaries 
dictionary 
lexemes 

=[ RECORD 5 ]+ 





blank 
Space symbols 


alias host 

description Host 

token | www.postgresql-support .de 
dictionaries | {simple} 

dictionary | simple 

lexemes | {www.postgresql-support .de} 


ts_debug 将 列 出 每 一 个 找到 的 记号 并 且 显示 有 关 该 记号 的 信息 。 用 户 会 看 到 解析 器 找 


到 了 哪些 记号 、 


用 到 的 词典 以 及 对 象 的 类 型 。 在 


笔者 的 例子 中 ， 解 析 器 找到 了 空格 、 单 词 


和 主机 。 用 户 可 能 还 会 看 到 数字 、email 地 址 和 很 多 其 他 的 东西 。 根 据 字 符 串 的 类 型 ， 


PostgreSQL 将 以 不 同 的 方式 来 处 理 。 例 如 ， 对 3 
义 的 。 


3.7.4 ”收集 词 统计 信息 


全 文 搜索 可 以 处 理 很 多 数据 。 为 了 让 
PostgreSQL 提供 了 pg_stat 函数 ， 它 会 返回 一 个 


SELECT * FROM ts stat('SELECT to tsv 
pg_available extensions') ORDER BY 2 


word | ndoc | nentry 
ee es 
function | 10 由 0 
data 1 10 | 10 


E 机 名 和 email 地 址 提取 词 干 绝 对 是 没有 意 





最 终 用 户 更 深入 地 查看 他 们 的 文本 ， 
词 的 列表 : 


ector(''english'', comment) FROM 
DESC LIMIT 3; 
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type lo WD 
(3 rows) 


word 列 包含 经 过 提取 词 干 处 理 的 词 ，ndoc 告诉 我 们 一 个 特定 词 出 现 的 文档 数 。 
nentry 表示 一 个 词 总 共 被 找到 多 少 次 。 


3.7.5 ”利用 排除 操作 符 


到 目前 为 止 ， 索引 已 经 被 用 来 加 速 操作 以 及 确保 唯一 性 。 不 过 ， 几 年 以 前 一 些 人 想 
出 了 索引 的 更 多 用 途 。 正 如 读者 在 本 章 中 已 经 见 过 的 ，GiST 支持 相交 、 重 登 、 包 含 等 很 
多 操作 。 那 么 为 什么 不 把 这 些 操作 用 来 管理 数据 完整 性 呢 ? 

这 里 是 一 个 例子 : 


test=# CREATE EXTENSION btree gist; 
test=# CREATE TABLE t reservation ( 
room int, 
from to tsrange, 
EXCLUDE USING GiST (room with =, 
from to with &&) 
); 
CREATE TABLE 


EXCLUDE USING GiST 子 句 定义 额外 的 约束 。 如 果 客 户 正 在 售卖 房间 ， 他 /她 可 能 想 
允许 不 同 的 房间 在 同一 时 间 被 预订 。 不 过 ， 客 户 不 会 想 在 同一 段 时 期 内 把 同一 间 房 卖 出 
两 次 。 在 笔者 的 例子 中 ，EXCLUDE 子 句 表达 的 意思 是 : 如 果 房 间 相等 ，from to with 中 
的 数据 就 不 能 重 倒 (&&)。 

下 面 的 两 行将 不 会 违背 约束 : 

test=# INSERT INTO t reservation VALUES (10, '["2017-01-01", 

220703=03 > 

INSERT 0 1 

test=# INSERT INTO 七 reservation VALUES (13, '["2017-01-01", 

"20317=03=03"]7 5 

INSERT 0 1 

不 过 ， 接 下 来 的 INSERT 将 会 导致 违背 ， 因 为 出 现 了 数据 重 麦 : 

test=# INSERT INTO 七 reservation VALUES (13, '["2017-02-02", 

“2207 0 

ERROR: conflicting key value violates exclusion constraint 





"t reservation room from to excl™" 
DETAIL: Key (room, from to)=(13, ["2017-02-02 00:00:00","2017-08-14 
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00:00:00"]) conflicts with existing key (room, from to)=(13, ["2017-01- 
0100:;00:00","2017-03-03 00:00:00"]) . 


排除 操作 符 的 使 用 非常 有 用 ， 它 可 以 为 用 户 提供 非常 高 级 的 方法 来 处 理 完整 性 。 
3.8 总 结 


章 全 都 是 有 关 索 引 的 内 容 。 我 们 已 经 学 到 了 何 时 PostgreSQL 将 决定 使 用 索引 以 及 
有 哪些 类 型 的 索引 存在 。 除 了 仅仅 使 用 索引 ， 还 可 以 实现 我 们 自己 的 策略 ， 用 自 定义 的 
操作 符 和 索引 策略 来 加 速 应 用 。 
对 于 那些 追求 极致 的 人 ，PostgreSQL 还 提供 了 自 定义 访问 方法 。 
第 4 章 全 部 都 是 有 关 高 级 SQL 的 内 容 。 很 多 人 并 没有 意识 到 SQL 的 真正 能 力 ， 因 此 
笔者 将 为 人 们 展示 一 些 高 效 的 、 更 加 高 级 的 SQL。 
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在 第 3 章 中 ， 读 者 已 经 学 到 了 索引 以 及 PostgreSQL 运行 自 定义 索引 代码 加 速 查询 的 
能 力 。 在 本 章 中 ， 读 者 将 学 到 有 关 高 级 SQL 的 内 容 。 本 书 的 大 部 分 读者 都 有 一 些 使 用 
SQL 的 经 验 ， 但 是 ， 经 验 表 明 ， 本 书 中 介绍 的 大 部 分 高 级 特性 并 非 广为人知 。 因 此 在 这 
里 介绍 这 些 特性 有 助 于 人 们 更 快 、 更 有 效 地 达成 他 们 的 目标 。 

本 章 的 主题 包括 : 

@ 分 组 集 。 

@ 排序 集 。 

@ 假想 聚集 。 

@ 窗口 函数 及 分 析 。 

在 本 章 结束 时 ， 读 者 将 能 够 理解 和 使 用 高 级 SQL 。 


4.1 引入 分 组 集 


每 一 个 SQL 的 高 级 用 户 应 该 都 很 熟悉 GROUP BY 和 HAVING 子 句 。 但 读者 是 否 也 
知道 CUBE、ROLLUP 以 及 GROUPING SETS? 如 果 不 知道 ， 本 章 将 值得 一 读 。 


4.1.1 ”装载 一 些 案例 数据 


为 了 让 读者 在 本 章 中 获得 更 愉快 的 体验 ， 笔 者 已 经 编写 了 一 些 案例 数据 ， 它 们 来 自 
于 BP 能 源 报告 : http://www.bp.com/en/global/corporate/energy-economics/statistical-review- 
of- world-energy.html。 


这 里 是 将 要 用 到 的 数据 结构 : 
test=# CREATE TABLE t oil ( 
region toxtr 
country text, 
year int, 
production Em 
consumption int 


x 
CREATE TABLE 
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用 curl 可 以 直接 从 我 们 的 网 站 下 载 这 一 测试 数据 : 
test=# COPY 七 oil FROM PROGRAM ' curl www.cybertec.at/secret/oil ext.txt '; 
COPY 644 


和 第 3 章 一 样 ， 该 文件 可 以 在 导入 之 前 先 下 载 它 。 在 一 些 操作 系统 上 ， 默 认 没 有 安 
装 curl， 因 此 对 于 很 多 人 来 说 先 下 载 该 文件 可 能 是 更 容易 的 选项 。 
这 份 数据 中 包含 世界 上 两 个 地 区 共计 14 个 国家 在 1965 年 到 2010 年 间 的 数据 : 


test=# SELECT region, avg (production) FROM t oil GROUP BY region; 





region | avg 
PR EN 
Middle East | 1992.6036866359447005 
North America | 4541.3623188405797101 
(2 rows) 


4.1.2 ”应 用 分 组 集 


GROUP BY 子 句 将 把 很 多 行 转变 成 每 一 组 一 行 。 不 过 ， 如 果 是 在 做 现实 生活 中 的 报 
表 ， 用 户 可 能 还 对 总 体 的 平均 值 感 兴趣 。 因 此 有 时 可 能 需要 一 个 附加 的 行 。 

可 以 这 样 来 做 : 

test=# SELECT region, avg (production) FROM 七 oil GROUP BY ROLLUP (region) 


region | avg 


Middle East | 1992.6036866359447005 
North America | 4541.3623188405797101 
| 2607.5139860139860140 


(3 rows) 


ROLLUP 将 会 注入 一 个 附加 的 行 ， 其 中 包含 总 体 的 平均 值 。 如 果 用 户 正 在 做 报告 ， 
它 就 非常 像 所 需要 的 总 结 行 。 无 须 运行 两 个 查询 ，PostgreSQL 可 以 仅 用 一 个 查询 就 提供 
上 述 这 样 的 数据 。 
当然 ， 这 种 操作 在 通过 不 止 一 列 分 组 时 也 能 使 用 : 
test=# SELECT region, country, avg (production) FROM 七 oil WHERE country 
IN ('USA', "Canada'， 'Iran', "'Oman') GROUP BY ROLLUP (region, country); 

region | country | avg 
ne 二 
Middle East | Iran 1°3631.6956521739130435 
Middle East | Oman | 586.4545454545454545 





人 


Middle East 

North America 
North America 
North America 


(7 rows) 


Canada 
USA 


Ke] 
记 
心 
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:91111 王 41113111 
-2173913043478261 
-3478260869565217 
-2826086956521739 
-7692307692307692 


。77 。 


在 这 个 例子 中 ，PostgreSQL 将 在 结果 集中 注入 3 行 。 一 行 针 对 Middle East， 一 行 针 
对 North America。 此 外 还 将 有 一 行 是 总 体 平均 值 。 如 果 用 户 正 在 构建 一 个 Web 应 用 ， 那 





集中 。 
如 果 立 即 想 要 显示 一 个 结果 ，ROLLUP 就 很 不 错 。 笔 者 总 是 用 它 来 把 最 终结 果 显 示 


给 最 终 用 户 。 不 过 ， 如 果 用 户 了 





的 灵活 性 。CUBE 关键 词 就 是 用 户 所 需要 的 东西 : 


test=# SELECT region, country, avg(production) FROM 七 oil WHERE country 


country + GROUP BY region + GROUP BY country + 总 体 均 值 。 因 
抽取 很 多 结果 以 及 各 个 层 E 


IN (USA "Canada”, VTran’ yr 
region | country | avg 
Se i 
Middle East | Iran | 3631.6956521739130435 
Middle East | Oman | 586.4545454545454545 
Middle East 1 M242 
North America | Canada | 2123.2173913043478261 
North America | USA | 9141.3478260869565217 
North America | | 5632.2826086956521739 
1 | 3906.7692307692307692 
| Canada | 2123.2173913043478261 
| Iran 1 3631.6956521739130435 
| Oman | 586.4545454545454545 
| USA | 9141.3478260869565217 


(11 rows) 





当前 的 结果 就 很 理想 ， 因 为 可 以 很 容易 地 构建 一 个 GUI 通过 过 滤 掉 空 值 来 钻 入 结果 


E 在 做 报告 ， 他 /她 可 能 想 要 预先 计算 更 多 数据 来 确保 更 好 


"Oman ') GROUP BY CUBE (region, country); 


注意 甚至 有 更 多 的 行 被 加 入 结果 中 。CUBE 创建 的 数据 是 : GROUP BY region, 








此 ， 其 整体 思想 是 同时 


看 的 聚集 。 结 果 立 方 体 包含 所 有 可 能 的 分 组 组 合 。 


ROLLUP 和 CUBE 实际 只 是 在 GROUPING SETS 子 句 之 上 的 便利 特性 。 通 过 
GROUPING SETS 子 句 ， 读 者 可 以 明确 地 列 出 想 要 的 聚集 : 


test=# SELECT region, country, avg (production) 


FROM t oil 


WHERE country IN ('USA', 


'Canada', 


ran 


'Oman') 
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GROUP BY GROUPING SETS ( (), region, country); 
region | country | avg 

Middle East 

North America 


EEE 

| 5632.2826086956521739 

| 3906.7692307692307692 
Canada | 2123.2173913043478261 

1 

1 

1 


Iran 3631.6956521739130435 
Oman 586.4545454545454545 
USA 9141.3478260869565217 


一 一 一 一 一 一 一 + 


(7 rows) 


在 这 里 ， 我 们 得 到 了 3 个 分 组 集 : 总 体 均值 、GROUP BY region 和 GROUP BY 
country。 如 果 读 者 想 要 组 合 region 和 country， 可 以 使 用 (region, country)。 

@ 性 能 研究 

分 组 集 是 一 种 强大 的 特性 ， 它 们 有 助 于 减少 昂贵 查询 的 数量 。 在 内 部 ，PostgreSQL 
基本 上 会 把 分 组 集 转 成 传统 的 GroupAggregates 来 实现 。GroupAggregate 节点 要 求 排序 好 
的 数据 ， 因 此 要 做 好 PostgreSQL 可 能 会 执行 很 多 临时 排序 的 准备 : 


test=# explain SELECT region, country, avg (production) 
FROM 七 oil 
WHERE country IN ('USA', "Canada'， "Iran'， 'Oman') 
GROUP BY GROUPING SETS ( (), region, country); 
QUERY PLAN 
GroupAggregate (cost=22.58..32.69 rows=34 width=52) 
Group Key: region 
Group Key: () 
Sort Key: country 
Group Key: country 
-> Sort (cost=22.58. .23.04 rows=184 width=24) 
Sort Key: region 
=> Seq Scan on t oil 
(cost=0.00..15.66 rows=184 width=24) 
Filter: (country = ANY 
('{USA,Canada, Iran,Oman}'::text[])) 


(9 rows) 


只 有 不 涉及 分 组 集 的 普通 GROUP BY 子 句 才 支持 哈 希 聚集 。 根 据 分 组 集 的 开发 者 
(Atri Shama) 所 说 (笔者 就 在 写本 章 之 前 刚 和 他 探讨 过 )， 对 哈 希 的 支持 不 值得 增加 。 
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此 看 起 来 PostgreSQL 已 经 有 了 一 种 有 效 的 实现 ， 虽 然 优化 器 在 这 方面 拥有 的 选择 比 普通 
GROUP BY 语句 更 少 。 


4.1.3 组 合 分 组 集 和 FILTER 子 句 


在 实际 应 用 中 ， 分 组 集 可 能 会 经 常 与 FILTER 子 句 组 合 在 一 起 。 其 思想 是 使 用 
FILTER 子 句 运行 部 分 聚集 。 

这 里 是 一 个 例子 : 

test=# SELECT region, 

avg (production) AS all, 


avg (production) FILTER (WHERE year < 1990) AS old,， 
avg (production) FILTER (WHERE year >= 1990) AS new 


FROM t oil 
GROUP BY ROLLUP (region); 
region | all | old 1 new 
一 一 -一 一 一 一 一 一 一 一 一 一 一 一 十 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 十 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 十 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 
Middle East 1 1992:603686635 | 1747.325892857 | 22542233333333 


North America | 4541.362318840 | 4471.653333333 | 4624.349206349 
| 2607.513986013 | 2430.685618729 | 2801.183150183 

(3 rows) 

这 个 例子 的 思想 是 ， 并 非 所 有 的 列 都 会 使 用 相同 的 数据 来 聚集 。FILTER 子 句 允许 用 
户 有 选择 地 传递 数据 给 那些 聚集 。 在 笔者 的 例子 中 ， 第 二 个 聚集 将 只 考虑 1990 年 之 前 的 
数据 ， 而 第 三 个 聚集 ?将 关注 较 新 的 数据 。 

如 果 可 以 把 条 件 移 到 WHERE 子 句 中 那 就 最 好 ， 因 为 从 表 中 取得 的 数据 当 
人 然 是 越 少 越 好 。 只 有 当 并 非 每 个 聚集 都 需要 被 WHERE 子 句 留 下 来 的 数据 时 才 
应 该 使 用 FILTER。 


FILTER 对 所 有 类 型 的 聚集 都 有 效 并 且 提供 了 一 种 简单 的 方式 对 数据 做 pivot 操作 。 
4.2 使 用 有 序 集 
有 序 集 是 一 种 强大 的 特性 ， 但 在 开发 者 社区 中 并 未 受到 广泛 的 关注 和 了 解 。 其 想法 


实际 上 很 简单 : 数据 被 正常 分 组 ， 然 后 将 每 个 分 组 中 的 数据 按照 给 定 条 件 排序 ， 最 后 在 
这 种 排序 好 的 数据 上 做 计算 。 





呈 原文 是 “第 二 个 聚集 ”， 应 为 笔 误 。 
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一 个 经 典 的 例子 是 中 位 数 计算 。 
9 中 位 数 是 中 间 的 值 。 例 如， 如 果 一 个 人 的 收入 是 中 位 数 ， 那 么 收入 比 他 
(她 ) 高 和 低 的 人 数 是 相等 的 。50% 的 人 收入 更 高 并 且 50% 的 人 收入 更 低 。 
一 种 得 到 中 位 数 的 方法 是 得 到 排序 好 的 数据 并 且 把 50% 移 入 数据 集中 。 这 里 有 一 个 
例子 展示 了 WITHIN GROUP 子 句 将 会 让 PostgreSQL 做 什么 : 


test=# SELECT region, percentile disc(0.5) WITHIN GROUP (ORDER BY 


production) FROM t oil GROUP BY 1; 
region | percentile disc 

上 SI 

Middle East | 1082 

North America | 3054 

(2 rows) 


percentile_disc 将 跳 过 该 组 的 50% 并 且 返 回想 要 的 值 。 注 意 ， 中 位 数 可 能 会 明显 地 偏 
离 均值 。 在 经 济 学 中 ， 中 位 数 收入 和 收入 均值 之 间 的 偏离 甚至 可 能 被 用 作 社 会 平等 的 指示 
器 。 中 位 数 相对 于 均值 越 高 ， 则 收入 越 不 平等 。 为 了 提供 更 高 的 灵活 性 ，ANSI 标准 没有 
只 提出 一 种 中 位 数 函 数 。 相 反 ，percentile_disc 允许 用 户 使 用 任何 介 于 0 和 1 之 间 的 值 。 

最 妙 的 是 用 户 甚至 可 以 把 有 序 集 和 分 组 集 一 起 使 用 : 


test=# SELECT region, 
percentile disc(0.5) WITHIN GROUP (ORDER BY production) 

FROM El 
GROUP BY ROLLUP (1); 

region | percentile disc 
汪 年 = 
Middle East [EL082 
North America | 3054 

1 L696 

(3 rows) 


在 这 种 情况 下 ，PostgreSQL 又 会 在 结果 集中 注入 额外 的 行 。 
按照 ANSI SQL 标准 所 提出 的 ，PostgreSQL 为 用 户 提供 了 两 种 percentile 函数 。 
percentile_disc 将 返回 一 个 值 ， 它 是 数据 集中 实际 包含 的 值 。percentile_cont 将 在 找 不 到 精 
确 匹 配 时 插值 。 下 面 的 例子 展示 了 这 一 效果 : 
test=# SELECT 
percentile disc(0.62) WITHIN GROUP (ORDER BY id) ， 


percentile cont (0.62) WITHIN GROUP (ORDER BY id) 
FROM generate series(1, 5) AS id” 
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Percentile disc | percentile cont 


(1 row) 


4 是 一 个 实际 存在 的 值 ， 而 3.48 是 被 插值 的 。 


PostgreSQL 不 


仅 提 供 了 percentile 函数 ， 还 有 mode 函数 可 用 在 分 组 中 查找 最 频繁 的 


值 。 在 展示 一 个 如 何 使 用 mode 函数 的 例子 之 前 ， 笔 者 编写 了 一 个 查询 来 展示 更 多 有 关 该 


表 内 容 的 信息 : 


test=# SELEC.' 
FROM t oi 
WHERE cou 
GROUP BY 
ORDER BY 
LIMIT 4; 

production 


(4 rows) 


T production, count(*) 

1 

ntry = "Other Middle East" 
production 

2 DESC 


3 个 不 同 的 值 出 现 了 正好 5 次。 当然 ，mode 函数 只 能 给 出 其 中 一 个 


test=# SELECT country, mode() WITHIN GROUP (ORDER BY production) 


FROM t oil 

WHERE country = 'Other Middle East' 

GROUP BY 1; 

country | mode 

pp EE 
Other Middle East | 48 
(1 row) 
这 个 例子 返回 了 最 频繁 的 值 ， 但 SQL 不 会 告诉 我 们 这 个 值 实际 出 现 得 有 多 频繁 。 甚 





可 能 该 数字 只 出 现 了 一 次 。 


4.3 理解 假想 聚 


假想 聚集 很 像 标准 的 有 序 集 。 不 过 ， 它 们 能 帮助 回答 一 种 不 同类 型 的 问题 : 如 果 一 
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个 值 在 其 中 ， 那 么 结果 会 怎样 ? 如 你 所 见 ， 这 不 是 关于 数据 库 内 实际 存在 的 值 ， 而 是 有 
关 一 个 特定 值 真实 存在 时 的 假想 结果 。 

PostgreSQL 提供 的 唯一 一 种 假想 函数 是 rank。 它 告诉 我 们 : 

test=# SELECT region, 


rank (9000) WITHIN GROUP 
(ORDER BY production DESC NULLS LAST) 


FROM t oil 
GROUP BY ROLLUP (1); 
region | rank 
Ss 让 
Middle East | 之 让 
North America | | 
1 47 
(3 rows) 


如 果 某 地 区 日 产 9000 桶 ， 那 将 是 北美 地 区 第 27 好 的 年 份 以 及 中 东 地 区 第 21 好 的 
年 份 。 
笔者 的 例子 使 用 了 NULLS LAST。 在 数据 被 排序 时 ， 空 值 通常 都 排 在 最 后 
Ce 面 。 不 过 ， 即 使 排序 顺序 反 过 来 ， 空 值 应 该 仍然 在 列表 的 末尾 ，NULLS LAST 
就 能 确保 这 一 点 。 


4.4 利用 窗口 函数 和 分 析 


在 讨论 了 有 序 集 之 后 ， 是 时 候 看 看 窗口 函数 了 。 肾 集 遵 循 一 种 相当 简单 的 原则 ; 取 
得 很 多 行 并 且 把 它们 转变 成 较 少 的 、 聚 集 起 来 的 行 。 窗 口 函 数 则 不 同 ， 它 把 当前 行 与 分 
组 中 的 所 有 行进 行 对 比 。 不 过 返回 的 行 数 没有 变化 。 

下 面 是 一 个 例子 : 


test=# SELECT avg (production) FROM t oil; 

















2607 5139 


(1 row) 


test=# SELECT country, year, production, consumption, avg(production 
OVER () 

FROM 七 oil 

LIMIT 4; 
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country | year | production | consumption | avg 
二 二 
USA | 1965 | 9014 i522 1 2607.5139 
USA L966 1 9379 | 12100 1 2607:5139 
USA UL967 | 0219 W267 | 2607.5139 
USA | 1968 | 10600 | 13405 | 2607.5139 
(4 rows) 


在 我 们 的 数据 中 ， 平 均 产 量 大 约 是 每 日 2600000 桶 。 这 个 查询 的 目标 是 把 这 个 值 增 
加 为 一 列 ， 这 样 就 很 容易 把 当前 行 与 总 体 均值 做 对 比 。 

一 定 记 住 OVER 子 句 是 必 不 可 少 的 ， 没 有 它 PostgreSQL 无 法 处 理 该 查询 : 

test=# SELECT country, year, production, consumption, avg (production) 

FROM t oil; 

ERROR: column "t oil.country" must appear in the GROUP BY clause or be 


used in an aggregate function 
LINE 1: SELECT country, year, production, consumption, avg (productio... 


这 确实 是 有 意义 的 ， 因 为 均值 必须 被 精确 定义 ， 数 据 库 引擎 不 能 接受 一 个 可 能 是 猜 
测 出 来 的 值 。 
的 其 他 数据 库 引 擎 可 能 会 接受 不 带 OVER 甚至 不 带 GROUP BY 子 名 的 聚集 
函数 。 不 过 ， 从 逻辑 的 角度 来 看 这 是 错误 的 并 且 是 对 SQL 的 一 种 违背 。 


4.4.1 划分 数据 


到 目前 为 止 ， 相 同 的 结果 也 都 可 以 很 轻易 地 用 一 个 子 查询 实现 。 不 过 ， 如 果 用 户 想 
要 的 比 总 体 均值 更 多 ， 子 查询 将 把 查询 变 成 器 梦 。 假 定 用 户 不 想 要 总 体 均值 而 是 正在 处 
理 的 国家 的 均值 ， 那 就 需要 一 个 PARTITION BY 子 句 : 


test=# SELECT country, year, production, consumption, avg (production) 
OVER (PARTITION BY country) FROM t oil; 





country | year | production | consumption | avg 
一 一- 一 一 一 -一 一 一 一 一 一 一 一 一 十 一 一 一 一 一 一 十 一 一 一 一 一 一 一 一 一 一 一 一 十 一 一 一 一 一 一 一 一 一 一 一 一 一 十 一 一 一 一 一 一 一 一 一 一 一 
Canada | S20 O08 22352173 
Canada 1 20120. 1 3332l 23.6 22322173 
Canada W20090| 3202 | 人 24000 27935273 
Iran L966 2132 1 49JIES36C3E6955 
Iran W20000 4352 | 1874 | 3631.6956 
Iran bh.2009 | 4249 | 20L12° .363L-.6956 
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这 里 的 重点 是 每 一 个 国家 都 被 分 配 了 一 个 该 国家 的 均值 。OVER 子 句 定义 我 们 正在 
查看 的 窗口 ， 在 这 个 例子 中 窗口 是 行 所属 的 国家 。 换 句 话说 ， 该 查询 返回 行 与 其 所 在 国 
家 的 所 有 行 的 对 比 。 


year 列 没有 被 排序 。 该 查询 并 没有 包含 一 个 明确 的 排序 顺序 ， 因 此 数据 可 
é9 能 会 以 随机 顺序 返回 。 记 住 ， 除 非 用 户 明确 地 说 明 想 要 的 顺序 否则 SQL 并 不 
承诺 有 序 的 输出 。 
基本 上 ，PARTITION BY 子 句 可 以 接受 任何 表达 式 。 通 常 大 部 分 人 会 使 用 一 个 列 来 
划分 数据 ， 例 如 : 


test=# SELECT year, production, 
avg (production) OVER (PARTITION BY year < 1990) 
FROM rol 
WHERE country = 'Canada' 
ORDER BY year; 








year | production | avg 

和 和 
1965 | 920 | 1631.6000000000000000 

1966 | 1012 | 1631.6000000000000000 

1990 | 1967 | 2708.4761904761904762 

L991 1 1983 | 2708.4761904761904762 

A | 2065 | 2708.4761904761904762 





这 里 的 重点 是 数据 划分 采用 表达 式 进 行 。year < 1990 可 能 返回 两 种 值 : true 和 false。 
根据 一 个 年 份 所 在 的 分 组 ， 它 将 会 被 分 配 1990 年 之 前 的 均值 或 者 1990 年 之 后 的 均值 ， 
从 这 里 可 以 看 到 PostgreSQL 确实 很 灵活 。 使 用 函数 来 判断 分 组 成 员 关 系 在 实际 应 用 中 并 
不 鲜 见 。 


4.4.2 在 窗口 中 排序 数据 


在 OVER 子 句 中 可 能 放 入 的 东西 并 非 只 有 PARTITION BY 子 句 。 有 时 候 有 必要 在 一 
个 窗口 中 排序 数据 。ORDER BY 将 以 一 种 特定 的 方式 为 聚集 函数 提供 数据 ， 例 如 : 


test=# SELECT country, year, production, 
min (Production) OVER (PARTITION BY country ORDER BY year) 
FROM Eo 
WHERE year BETWEEN 1978 AND 1983 
AND country IN ('Iran', ‘Oman'); 
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country year production | min 
ET Ps 
Iran 1978 5302 | 5302 
Iran 证 979 3218 1 3218 
Iran 1980 1479 | 1479 
Iran 1981 3132710 L321 
Iran 1982 过 3970 1 S21 
Iran 1983 2454 | 1321 
Oman 1978 314 | 314 
Oman L979 395 29 
Oman 1980 285 | :285 
Oman 1981 330 285 





对 于 1978 年 到 1983 年 这 个 时 间 段 ， 从 我 们 的 数据 集中 选中 了 两 个 国家 (伊朗 和 阿 
曼 )。 记 住 ， 在 1979 年 伊朗 发 生 一 次 革命 ， 所 以 对 其 原油 产量 有 一 些 影响 ， 上 述 数 据 反 
映 了 这 一 情况 。 

这 个 查询 所 做 的 事情 是 计算 到 时 间 序 列 中 一 个 特定 时 间 点 为 止 的 最 小 产量 。“ 到 目前 
为 止 ” 是 让 SQL 初学 者 记 住 OVER 子 句 中 ORDER BY 子 句 行为 的 最 好 方式 。 在 这 个 例 
子 中 ，PARTITION BY 子 句 将 为 每 个 国家 创建 一 个 分 组 并 且 在 分 组 中 排序 数据 。min 函数 
将 在 有 序 的 数据 上 循环 并 且 提 供 所 需 的 最 小 值 。 

如 果 读 者 之 前 对 窗口 函数 并 不 熟悉 ， 那 么 应 该 注意 的 是 ， 使 用 ORDER BY 子 句 所 产 
生 的 效果 确实 不 同 : 

test=# SELECT country, year, production, 

min (Production) OVER ()， 

min (production) OVER (ORDER BY year) 
FROM ie 地 
WHERE year BETWEEN 1978 AND 1983 

AND country = 'Iran'; 


hy 





country | year | production | min | min 
让 
Iran 1 1978. 1 本 02 1 T3200 5302 

Iran | 32100 | 531.321 1 3218 

Iran 98001 EE A I x 4 BO a] 

Iran (We :2 | 3210 T1321 1 132 

Iran | Ne 1 0 | 之 3 2 二 3 之 和 

Iran lm9830 之 有 454 32 | 二 3 之 

(6 rows) 


如 果 使 用 的 聚集 不 带 ORDER BY， 它 将 自动 地 取 窗 口中 整个 数据 集 的 最 小 值 。 而 有 
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ORDER BY 时 就 不 是 这 样 : 它 将 总 是 给 定 顺序 中 到 目前 为 止 的 最 小 值 。 
4.4.3 ”使 用 滑动 窗口 


到 目前 为 止 ， 我们 所 使 用 的 窗口 都 是 静态 的 。 然 而 ， 对 于 移动 平均 这 类 计算 来 说 这 
四 从 哆 。 移动 聚集 需要 一 个 滑动 窗口 ， 滑 动 窗口 会 随 着 数据 的 处 理 而 移动 。 
这 里 有 一 个 如 何 实现 移动 平均 的 例子 


test=# SELECT country, year, production, 

min (production) OVER (PARTITION BY country 
ORDER BY year ROWS 
BETWEEN 1 PRECEDING 
AND 1 FOLLOWING) 

FROM t oil 

WHERE year BETWEEN 1978 AND 1983 

AND country IN ('Iran', 'Oman'); 





country year production | min 
== 三 
Iran 978 S302 32 
Iran ST 32109 1 二 A 
Iran 1980 = 
Iran 981 T3220 L321 
Iran 982 ci Sb 
Iran 983 2454 | 2397 
Oman 978 314 1 295 
Oman 979 2 
Oman 980 2857l 9S 
Oman 981 3300 228S 
Oman 1982 S38° 1 .330 
Oman 1983 391700 338. 








(12 rows) 


重要 的 事情 是 移动 窗口 应 该 与 ORDER BY 子 句 一 起 使 用 ， 和 否则 就 会 有 大 量 问题 。 
PostgreSQL 实际 上 会 接受 那样 的 查询 ， 但 是 其 结果 会 是 彻头彻尾 的 垃圾 。 记 住 ， 将 事先 
没有 排序 的 数据 交 给 一 个 滑动 窗口 只 会 导致 随机 数据 。 

“ROWS BETWEEN 1 PRECEDING and 1 FOLLOWING 1” 定 义 了 窗口 。 在 笔者 的 例 
子 中 ， 被 使 用 的 最 多 有 3 行 : 当前 行 、 当 前 行 的 前 一 行 以 及 当前 行 的 后 一 行 。 为 了 展示 
滑动 窗口 如 何 工作 ， 试 试 下 面 的 例子 : 

test=# SELECT *, 
array_agg (id) OVER 
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(ORDER BY id ROWS BETWEEN 1 PRECEDING AND 1 FOLLOWING) 
FROM generate _ series(1，5) AS id; 
id | array agg 


Ey 
ZL 
3 | M273raT 
4 | {3,4,5} 
5 | {4,5} 
(5 rows) 


array_agg 函数 将 把 一 个 值 列表 转变 成 一 个 PostgreSQL 数组 ， 它 将 有 助 于 解释 滑动 窗 
口 如 何 操作 。 
实际 上 这 个 微不足道 的 查询 却 有 一 些 非 常 重要 的 方面 。 读 者 所 看 到 的 是 第 一 个 数组 
只 包含 两 个 值 。 在 1 之 前 没有 项 ， 因 此 该 数组 并 未 充满 。PostgreSQL 并 未 增加 空 值 项 ， 
因为 它们 会 被 聚集 忽略 。 同 样 的 事情 发 生 在 数据 的 末尾 。 
不 过 ， 滑 动 窗口 还 提供 了 更 多 东西 。 有 一 些 关 键 词 可 以 被 用 来 指定 滑动 窗口 : 
test=# SELECT *, 
array agg (id) OVER 
(ORDER BY id ROWS BETWEEN UNBOUNDED PRECEDING 
AND 0 FOLLOWING) 
FROM generate series(1, 5) RS id; 
id | array agg 


(5 rows) 


UNBOUNDED PRECEDING 指定 当前 行 之 前 的 所 有 东西 都 将 在 该 窗口 中 。 与 
UNBOUNDED PRECEDING 相对 的 是 UNBOUNDED FOLLOWING: 


test=# SELECT *, 
array_agg (id) OVER 
(ORDER BY id ROWS BETWEEN 2 FOLLOWING 
AND UNBOUNDED FOLLOWING) 
FROM generate series(1, 5) AS id 
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id | array agg 


rows) 

如 读者 所 见 ， 也 可 以 使 用 一 个 表示 未 来 的 窗口 ，PostgreSQL 在 这 一 点 上 非常 灵活 。 

4.4.4 提取 窗口 子 句 

窗口 函数 允许 我 们 在 结果 集中 增加 联机 计算 的 列 。 然 而 ， 经 常 发 生 的 事情 是 很 多 这 
样 的 列 都 基于 同一 个 窗口 。 把 同样 的 子 句 一 遍 又 一 遍地 写 在 查询 中 绝对 不 是 什么 好 3 
意 ， 因 为 这 样 会 让 查询 变 得 很 难 阅 读 和 维护 。 

WINDOW 子 句 允许 开发 者 预定 义 一 个 窗口 ， 并 且 将 它 用 在 查询 中 的 多 个 位 置 。 例 如 : 


SELECT country, year, production, min(production) OVER (w), max (production) 


芭 





mr 


OVER (w) 
FROM ERO 
WHERE country = 'Canada' 


AND year BETWEEN 1980 AND 1985 
WINDOW w AS (ORDER BY year); 
country | year | production 


1 

十 十 
Canada | 1980 | 1764 | 1764 | 1764 
Canada | 1981 | 1610 | 1610 | 1764 
Canada | 1982 | 15900 125900 | £264 
Canada | 1983 | 1661 | 1590 | 1764 
Canada | 1984 | TS SOO EAS 
Canada | 1985 | 012 2590 | 29812 
(6 rows) 


这 个 例子 显示 min 和 max 将 使 用 同一 个 子 句 。 
当然 ， 可 以 有 多 于 一 个 WINDOW 子 句 一 一 PostgreSQL 在 这 里 未 对 用 户 施 以 严格 的 
限制 。 


4.4.5 “使 用 内 建 窗口 函数 
在 为 读者 介绍 了 基本 概念 之 后 ， 现 在 就 可 以 看 看 PostgreSQL 支持 哪些 可 以 立即 使 用 
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的 窗口 函数 。 读 者 已 经 见 过 了 使 用 所 有 标准 聚集 函数 的 窗口 ， 在 那些 函数 之 上 ， 
PostgreSQL 还 提供 了 一 些 附 加 函数 ， 它 们 只 用 于 窗口 和 分 析 。 
在 本 节 中 将 解释 并 讨论 一 些 非常 重要 的 函数 。 


1，rank 和 dense_rank 函数 





在 笔者 而 言 ，rank 和 dense rank 函数 是 最 为 突出 的 函数 。rank 函数 返回 当前 行 在 其 
窗口 中 的 编号 ， 从 1 开始 计数 。 
这 里 有 一 个 例子 : 
test=# SELECT year, production, 
rank() OVER (ORDER BY production) 
FROM t oil 


WHERE country = 'Other Middle East'" 
ORDER BY rank 














LIMIT 7; 

year production | rank 
二 全 二 二 二 于 二 一 三 二 二 二 二 一 一 二 一 二 由 二 三 一 一 二 二 
2001 47 | 1 
2004 48 | 区 
2002 48 | 之 
1999 48 | 区 
2000 48 | 4 
2003 48 | 2 
1998 49 1| 7 
(7 rows) 


rank 列 将 会 对 那些 行 编 号 。 注 意 例子 中 很 多 行 是 相等 的 。 因 此 rank 将 从 2 直接 跳 到 
7。 如 果 想 避免 这 样 的 事情 ， 可 以 使 用 dense rank 函数 : 


test=# SELECT year, production, 
dense rank() OVER (ORDER BY production) 
FROM t oil 
WHERE country = "Other Middle East" 
ORDER BY dense rank 


LIMIT 7; 
year | production | dense rank 
RO I 
2001 | 47 1 下 
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2003 | 48 1 pA 
1998 | 49 1 3 
(7 rows) 
PostgreSQL 会 把 编号 弄 得 更 加 紧密 ， 中 间 不 会 有 间隔 。 
2. ntile 函数 
一 些 应 用 要 求 把 数据 划分 成 完美 相等 的 分 组 ，ntile 函数 可 以 做 到 这 一 点 。 


下 面 的 例子 展示 了 数据 如 何 被 划分 成 分 组 : 


test=# SELECT year, production, 
ntile(4) OVER (ORDER BY production) 
FROM t Gil 
WHERE country = "Iraq'" 
AND year BETWEEN 2000 AND 2006; 





year production | ntile 
A ee 
2003 竺 34 |] 1 

2005 L833 h 

2006 L999] 到 

2004 2030 | 之 

2002 ZI06R| 三 

2001 2522, 1] 3 

2000 2 | 4 

(7 rows) 


该 查询 把 数据 划分 成 4 个 分 组 。 问 题 在 于 这 里 只 选择 了 7 行 ， 这 样 就 不 可 能 创建 4 个 
平均 的 分 组 。 如 你 所 见 ，PostgreSQL 将 填 满 前 三 个 分 组 并 且 让 最 后 一 个 分 组 小 一 点 。 可 
以 确信 末尾 的 分 组 将 总 是 比 其 他 分 组 小 一 点 。 


把 这 个 例子 中 只 用 了 少量 的 行 。 在 实际 应 用 中 将 涉及 数 百 万 行 ， 因 此 如 果 分 
组 不 完美 地 相等 也 没有 问题 


ntile 函数 通常 不 会 被 单独 使 用 。 当 然 ， 它 有 助 于 为 一 行 分 配 一 个 分 组 ID。 不 过 ,在 
实际 应 用 中 ， 人 们 想 要 在 那些 分 组 之 上 执行 计算 。 假 定 用 户 想 要 为 其 数据 创建 一 种 分 位 
数 分 布 ， 下 面 的 例子 可 以 做 到 : 

test=# SELECT grp, min(production), max(production), count(*) 

FROM ( 


SELECT year, production, 
ntile(4) OVER (ORDER BY production) AS grp 
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FROM t oil 

WHERE country = "Iraq" 

) AS x 

GROUP BY ROLLUP (1); 

grp | min | max | count 
一 -一 一 一 十 一 一 一 一 一 一 十 一 一 一 一 一 一 十 一 一 一 一 一 一 一 
1 lr2850 | L228 Lz 
2 ,Beh I rl ly 
3 W999 | 24225 | 3 
4 1 2428 | 3489 | a 

1 285 | 3489 1 46 

(5 rows) 


最 重要 的 是 该 计算 不 能 在 一 步 中 完成 。 当 笔者 在 Cybertec (www.cybertec.at) 上 做 
SQL 培训 课程 时 ， 笔 者 尝试 向 学 员 解 释 ， 只 要 不 知道 如 何 一 次 完成 全 部 工作 ， 屠 就 考虑 使 
用 一 个 子 查询 。 在 分 析 工 作 中 这 通常 是 一 个 好 主意 。 在 这 个 例子 中 ， 所 做 的 第 一 件 事 〈 在 
子 查 询 中 ) 是 为 每 一 组 贴 一 个 分 组 标签 ， 然 后 在 主 查 询 中 取得 那些 分 组 并 且 进 行 处 理 。 

最 终 的 结果 就 已 经 是 可 以 在 实际 应 用 (可 能 是 图 表 旁 边 的 图 例 ) 中 使 用 的 东西 。 


3，lead 和 lag 函数 


虽然 ntile 函数 对 于 把 一 个 数据 集 划 分 为 分 组 很 重要 ， 这 里 的 lead 和 lag 函数 可 以 在 
结果 集 内 移动 行 。 一 种 典型 的 用 例 是 计算 一 年 和 接 下 来 一 年 的 产量 差 ; 


test=# SELECT year, production, 
lag (production, 1) OVER (ORDER BY year) 


FROM t_ oil 


WHERE country = 


LIMIT 5; 


year | production 





"Mexico'" 


在 实际 计算 产量 中 的 变化 之 前 ， 还 是 先 看 看 lag 函数 会 做 什么 。 读 者 可 以 看 到 列 被 按 
照 一 行 移动 。 数 据 按 照 ORDER BY 子 句 的 定义 进行 移动 。 在 笔者 的 例子 中 ， 它 表示 向 
下 。ORDER BY DESC 子 句 当然 会 让 数据 向 上 移动 。 
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有 了 这 个 基础 后 ， 查 询 就 很 容易 了 : 


test=# SELECT year, production, 
production - lag(production, 1) OVER (ORDER BY year) 
FROM ”七 oil 
WHERE country = "Mexico' 


LIMIT 3; 
year | production | ?column? 
三 二 SEE 三 上 二 
1965 | 362 | 
1966 | Ey | 8 
1967 | 411 | 41 
(3 rows) 


所 有 要 做 的 就 是 计算 差异 而 已 ， 就 好 像 有 了 另 一 列 一 样 。 注 意 ，1lag 函数 有 两 个 参 
数 。 第 一 个 参数 表示 要 显示 哪 一 列 ， 第 二 个 参数 告诉 PostgreSQL 想 要 移动 多 少 行 。 因 此 
放 上 7 就 表示 对 任何 行 都 要 减 去 7 个 行 。 


的 第 一 个 值 为 空 (其 他 没有 前 序 值 的 延迟 行 也 是 如 此 )。 


lead 函数 是 lag 函数 的 反面 : 它 将 把 行 向 上 移 而 不 是 向 下 移 : 


test=# SELECT year, production, 
production - lead(production, 1) OVER (ORDER BY year) 


FROM t oT1 
WHERE country = 'Mexico' 
LIMIT 3; 
year | production | ?column? 
3 EE 
1965 | 362 =8 
1966 | 370" |] = 
L967 | a =28 
(3 rows) 
基本 上 ， 对 于 lead 和 lag 列 ，PostgreSQL 也 会 接受 负 值 。 因 此 ，lag(production, -1) 是 


lead(production,1) 
加 清晰 。 
到 目前 为 止 ， 





的 一 种 蔡 代 品 。 不 过 ， 使 用 正确 的 函数 把 数据 移 向 用 户 想 要 的 方向 会 更 





读者 已 经 看 到 了 如 何 延 迟 单个 列 。 在 大 部 分 应 用 中 延迟 单个 值 将 是 大 








部 分 开发 人 员 使 








的 标准 情况 。 关 键 是 ，PostgreSQL 还 能 做 更 多 事情 。 例 如 可 以 延迟 整 





WE 
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test=# \x 
Expanded display is on. 
test=# SELECT year, production, 
lag(t oil, 1) OVER (ORDER BY year) 
FROM 七 oil 
WHERE country = 'USA' 





LIMIT 3; 
| RECORD I ===>==== 人 2 
year L965 
production | 9014 
lag | 
= ,JRECORD 2 二 = 一 一 一 一 一 一 一 二 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 二 
year | 1966 
production | 9579 
lag | ("North America",USA,1965,9014,11522) 
RECORD 3 
year yt 
production | 10219 
lag | ("North America",USA,1966,9579,12100) 


这 里 最 美妙 的 事情 是 ， 可 以 把 不 止 一 个 单 值 拿 来 与 以 前 的 行 比较 。 但 问题 是 
PostgreSQL 只 会 把 整个 行 作为 一 种 组 合 类 型 返回 ， 因 此 很 难 去 处 理 它 。 为 了 分 解 一 种 组 
合 类 型 ， 可 以 使 用 圆 括号 和 一 个 星 号 : 


test=# SELECT year, production, 
(lag(t oil, 1) OVER (ORDER BY year)).* 


FROM t oil 
WHERE country = 'USA' 
LIMIT 3; 
vear | Breod al region | country | year | prod | consumption 
--- 一 -一 二 一 一 一 一 一 一 一 十 一 一 一 一 一 一 一 一 一 一 一 一 十 一 一 一 一 一 一 一 一 一 十 一 一 一 一 一 一 十 一 一 一 一 一 一 十 一 一 一 一 一 一 一 一 一 一 一 一 一 
GS 1 1 1 
1966 | 9579 | N. America | USA i"1965 1 -9014" | 522 
1967 | 10219 | N. America | USA LL9660 .957 12100 
(3 rows) 


这 有 什么 用 呢 ? 延迟 一 整个 行将 会 让 它 无 法 查看 数据 是 否 被 插入 多 次 。 它 对 于 
间 序 列 中 检测 重复 行 〈 或 者 接近 于 重复 的 行 ) 来 说 非常 简单 。 
看 看 下 面 的 例子 : 


test=# SELECT * FROM ( 
SELECT t oil, lag(t oil) 


生 
也 
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OVER (ORDER BY year) 
FROM t oil 
WHERE country = 'USA' 
) AS x 
WHERE t oil = lag; 
t oil | lag 
Sg a 
(0 rows) 


当然 ， 样 例 数据 中 并 不 包含 重复 。 但 是 在 实际 的 例子 中 ， 重 复 很 容易 发 生 ， 并 且 即 
便 没有 主键 也 很 容易 检测 到 它们 。 
t_oil 实际 上 是 一 整 行 。 子 查询 返回 的 lag 也 是 一 个 完整 的 行 。 在 
@ PostgreSQL 中 ， 在 组 成 域 相同 的 情况 下 可 以 直接 比较 组 合 类 型 。PostgreSQL 将 
会 逐个 比较 其 中 的 域 。 











4， first_value、nth_value 和 last_value 函数 
有 时 ， 有 必要 基于 一 个 数据 窗口 的 第 一 个 值 来 计算 数据 。 做 这 件 事情 的 函数 无 疑 就 
是 first_value: 


test=# SELECT year, production, 
first value (production) OVER (ORDER BY year) 


FROM t oil 
WHERE country = "Canada'" 
LIMIT 4; 
year | production | first value 
a Ds 
1965 | 920 1 920 
1966 | Tol ll 920 
L967 1106 | 920 
1968 | 1194° 1 920 
(4 rows) 


同样 ， 需 要 一 个 排序 顺序 来 告诉 系统 第 一 个 值 究竟 在 哪里 。 然 后 PostgreSQL 将 把 同 
样 的 值 放 在 最 后 一 列 中 。 如 果 想 要 找到 窗口 中 的 最 后 一 个 值 ， 只 需要 用 last_value 函数 代 
蔡 first_value。 

如 果 用 户 的 兴趣 不 在 于 第 一 个 或 者 最 后 一 个 值 ， 而 是 想 要 找 某 个 在 中 间 的 值 ， 
PostgreSQL 还 提供 了 nth_value 函数 : 
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test=# SELECT year, production, 


nth value (production, 3) OVER (ORDER BY year) 


FROM t oil 
WHERE country = 'Canada'; 
year | production | nth value 


人 下 
1965 | 9320 1 
1966 | LO0T2 
| Ebi | 1106 
1968 | Eh | 1106 


。95。 


在 这 个 例子 中 ， 第 三 个 值 将 被 放 到 最 后 一 列 中 ， 不 过 ， 注 意 前 两 行 的 最 后 一 列 是 空 


的 。 问 题 在 于 当 PostgreSQL 开始 处 理 数据 时 ， 第 三 个 值 还 不 知道 。 








姑 此 ， 对 前 两 行 就 会 








放 入 空 值 。 现 在 的 问题 是 : 我 们 怎样 才能 让 时 间 序 列 更 加 完整 ， 并 且 把 那 两 个 空 值 蔡 换 


成 后 面 要 到 来 的 数据 ? 
这 里 有 一 种 方法 : 


test=# SELECT *, 
min (nth_ value) OVER () 





FROM ( 
SELECT year, production, 
nth value (production, 3) OVER (ORDER BY year) 


FROM t oil 

WHERE country = 'Canada' 

ja5. 过 

LIMIT 4; 

year | production | nth value | min 
-一 -一 二 一 一 一 一 一 一 一 一 一 一 一 一 十 一 一 一 一 一 一 一 一 一 一 一 十 一 一 一 一 一 一 
L965 920 1 | 1106 
1966 | LOL2l | 1106 
L967 1] 1106 | 1106 | 1106 
1968 | T1194 证 1106 | 1106 
(4 rows) 


子 查询 将 创建 不 完整 的 时 间 序 列 ， 顶 层 的 SELECT 将 补 全 数据 。 这 里 的 情节 是 : 只 
是 补 全 数据 可 能 会 更 复杂 ， 因 此 比 起 一 步 做 完 来 说 ， 一 个 子 查询 可 能 会 带 来 一 些 机 会 ， 





增加 某 种 更 复杂 的 逻辑 。 
5。，row_number 函数 


本 节 中 要 讨论 的 最 后 一 个 函数 是 row_number， 它 可 以 被 用 来 返回 一 个 虚拟 ID 。 听 起 
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来 简单 吧 ， 下 面 是 它 的 例子 : 


test=# SELECT country, production, 
row number() OVER (ORDER BY production) 





FROM t oil 
LIMIT 3; 
country | production | row number 
a Es 
Yemen 1 0 于 
Syria | 2 2 
Yemen 1 za | 3 
(3 rows) 


row_number 函数 简单 地 为 行 分 配 一 个 编号 ， 其 中 绝对 不 会 有 重复 。 
这 里 有 趣 的 一 点 是 即使 没有 排序 〈 如 果 顺 序 没有 关系 ) 它 也 能 工作 : 
test=# SELECT country, production, 

row number () OVER () 


FROM 七 oil 

LIMIT 32 
country | production | row number 
二 闪 三 二 二 所 二 二 全 二 三 
USA | 9014 | . 
USA | S579 2 
USA 1 下 029 | 
(3 rows) 


4.5 编写 自己 的 聚集 


在 本 书 中 用 到 的 大 部 分 都 是 PostgreSQL 系统 提供 的 函数 。 不 过 ，SQL 提供 的 东西 可 
能 并 不 能 完全 满足 用 户 。 好 消息 是 可 以 向 数据 库 引擎 增加 自己 的 聚集 。 在 本 节 中 读者 将 
会 学 到 如 何 做 这 件 事 。 

4.5.1 创建 简单 的 聚集 

这 个 例子 的 目标 是 解决 一 个 非常 简单 的 问题 : 如 果 叫 了 一 辆 出 租车 ， 通 常 必 须 支 付 
起 步 价 〈 例 如 ，2.50 欧元 )。 那 么 让 我 们 假设 每 公里 顾客 需要 支付 2.20 欧元 。 现 在 问题 来 


了 : 一 趟 行程 的 总 价 是 多 少 ? 
当然 ， 这 个 例子 简单 到 完全 可 以 不 用 自 定义 聚集 来 解决 ， 不 过 ， 还 是 让 我 们 看 看 上 
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自 定义 聚集 应 该 怎么 做 。 首 先 创建 一 些 测试 数据 : 


test=# CREATE TABLE t taxi (trip id int, km numeric); 
CREATE TABLE 
test=# INSERT INTO t taxi VALUES 
(lr ON le 3 ML MAS 
《定向 
INSERT 0 5 


PostgreSQL 提供 了 CREATE AGGREGATE 命令 来 创建 聚集 。 这 个 命令 的 语法 已 经 变 
得 如 此 强大 和 元 长 ， 因 此 在 本 书 中 包括 \h 的 输出 已 经 没有 任何 意义 。 笔 者 推荐 去 参考 
PostgreSQL 文档 (可 以 在 https://www.postgresql.org/docs/devel/static/sql-createaggregate.html 
找到 )。 

编写 一 个 聚集 所 需要 的 第 一 个 部 分 是 一 个 函数 ， 每 一 行 都 会 调用 它 。 该 函数 将 接受 
一 个 中 间 值 和 取 自 被 处 理 行 的 数据 。 这 里 是 一 个 例子 : 


test=# CREATE FUNCTION taxi per line (numeric, numeric) 
RETURNS numeric AS 

$$ 

BEGIN 

RAISE NOTICE 'intermediate: %, per row: %', $1, $2; 
RETURN $1 + $2*2.2; 

END; 

$$ LANGUAGE ‘plpgsql'; 

CREATE FUNCTION 


现在 已 经 可 以 创建 一 个 简单 的 聚集 : 


test=# CREATE AGGREGATE taxi price (numeric) 
( 





INITCOND = 2.5, 
SFUNC = taxi per line, 
STYPE = numeric 
); 
CREATE AGGREGATE 
如 前 所 述 ， 每 一 次 行程 从 踏 进出 租车 开始 价格 就 是 2.50 欧元 ， 这 由 INITCOND ( 初 
始 条 件 ) 定义 ， 它 表示 每 个 分 组 的 起 始 值 。 然 后 对 分 组 中 的 每 一 行 都 调用 一 个 函数 ， 在 
笔者 的 例子 中 这 个 函数 是 已 经 定义 好 的 taxi per line。 如 你 所 见 ， 它 需要 两 个 参数 。 第 一 
个 参数 是 一 个 中 间 值 。 那 些 额外 的 参数 〈 可 能 有 很 多 ) 是 用 户 传递 给 函数 的 。 
下 面 的 语句 展示 了 什么 时 间 以 及 怎样 传 入 哪些 数据 : 
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test=# SELECT trip id, taxi price (km) 


NOTICE: 
NOTICE: 
NOTICE: 
NOTICE: 
NOTICE: 
tai dl 


2 
(2 rows) 


FROM t taxi 
GROUP BY 1; 
intermediate: 
intermediate: 
intermediate: 
intermediate: 
intermediate: 
| taxi price 


2.5, per row: 4.0 


有 
18 


50 per LOW 3 
-3 Poer Tow a.5 


DOr POW TSS 
6.68, per row: 4.5 


系统 从 行程 一 和 2.50 欧元 (初始 条 件 ) 开始 。 然 后 增加 了 4 公里 。 现 在 的 总 价 是 2.50 + 
4x2.2。 然 后 加 入 下 一 行 ， 这 会 增加 3.2X2.2， 以 此 类 推 。 因 此 第 一 趟 行程 费用 是 28.24。 
然后 下 一 趟 行程 开始 。 同 样 ， 它 开始 于 一 个 新 的 初始 条 件 并 且 PostgreSQL 会 为 每 一 
行 调用 一 次 函数 。 
在 PostgreSQL 中 一 个 聚集 也 可 以 自动 地 作为 窗口 函数 使 用 ， 不 需要 任何 额外 的 步 
又 一 一 用 户 可 以 直接 使 用 该 聚集 : 


test=# SELECT *, taxi _ price (km) OVER (PARTITION BY trip id ORDER BY km) 


FROM 七 | 
NOTICE : 
NOTICE : 
NOTICE : 
NOTICE : 
NOTICE : 
trip 1d 


(5 rows) 


Eaxds 

intermediate: 
intermediate: 
intermediate: 
intermediate: 
intermediate: 


2,.57 per roWw: 332 
9.54, per row: 4.0 


18 . 


34, per row: 4.5 


2.5, per row: 1.9 
6.68, per row: 4.5 
| km | taxi price 


这 个 查询 给 出 的 是 到 行程 中 一 个 给 定点 时 的 价格 是 多 少 。 
我 们 已 经 定义 的 聚集 将 在 每 一 行 上 调用 一 次 函数 。 不 过 ， 用 户 怎样 才能 计算 平均 值 
或 者 类 似 的 值 ? 只 有 增加 一 个 FINALFUNC 计算 才能 做 到 。 为 了 展示 FINALFUNC， 可 
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以 扩展 一 下 刚才 的 例子 。 假 定 想 要 在 下 车 时 给 司机 10% 的 小 费 ， 这 10% 必 须 在 总 价钱 知 
道 之 后 立刻 加 到 总 价 上 ， 这 就 是 FINALFUNC 介入 的 时 机 。 下 面 将 展示 其 实现 : 


test=# DROP AGGREGATE taxi price (numeric) 
DROP AGGREGRATE 


首先 删除 旧 的 聚集 ， 然 后 定义 FINALFUNC， 它 会 得 到 中 间 结 果 作 为 参数 然后 玩 些 
魔术 : 
test=# CREATE FUNCTION taxi final (numeric) 
RETURNS numeric RS 
$$ 
SELECT $1 * 1.1; 
$$ 
LANGUAGE sql IMMUTABLE; 
CREATE FUNCTION 


在 这 个 例子 中 计算 非常 简单 一 一 将 10% 加 到 总 和 上 。 
一 旦 该 函数 被 部 署 好 ， 就 可 以 重新 创建 聚集 : 


test=# CREATE AGGREGATE taxi price (numeric) 
( 
INITCOND = 2.5, 
SFUNC = taxi per line, 
STYPE = numeric, 
FINALFUNC = taxi final 
); 
CREATE AGGREGATE 


test=# SELECT trip id, taxi price(km) 
FROM t taxi 
GROUP BY 1; 

NOTICE: intermediate: 2.5, per row: 4.0 


trip id | taxi price 


ll 31.064 
之 吓 站 82236 


PostgreSQL 会 自动 搞定 所 有 的 分 组 之 类 的 工作 。 
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对 于 简单 的 计算 ， 中 间 结 果 可 以 使 用 简单 数据 类 型 。 但 是 ， 不 是 所 有 的 操作 都 可 以 
通过 只 传递 简单 数字 和 文本 就 能 解决 。 幸 运 的 是 ，PostgreSQL 人 允许 使 用 组 合 数据 类 型 ， 
它 也 能 用 作 中 间 结 果 。 

想象 一 下 用 户 想 要 计算 某 种 数据 〈 可 能 是 一 种 时 间 序 列 或 者 其 他 ) 的 均值 。 中 间 结 
果 可 能 长 这 样 : 

test=# CREATE TYPE my intermediate AS (c int4, s numeric); 

CREATE TYPE 

请 放心 地 组 合 任意 类 型 来 服务 于 你 的 程序 ， 只 需要 把 它 作为 第 一 参数 传递 给 聚集 函 
数 ， 并 且 按 照 需要 把 数据 作为 额外 的 参数 加 入 即 可 。 


4.5.2 ”为 并 行 查询 增加 支持 


读者 已 经 看 到 的 只 是 一 个 简单 的 聚集 ， 它 不 能 支持 并 行 查询 。 为 了 解决 这 一 挑战 ， 
接 下 来 的 几 个 例子 全 都 与 改进 和 提速 有 关 。 
在 创建 聚集 时 ， 用 户 可 以 有 选择 地 定义 下 列 选项 : 


[ ，PRARALLEL = { SAFE | RESTRICTED | UNSAFE } ] 


默认 情况 下 聚集 不 支持 并 行 查询 。 不 过 ， 出 于 性 能 原因 ， 明 确 地 说 明 聚 集 能 干什么 
是 有 意义 的 。 

@ UNSAFE: 这 种 模式 下 不 允许 并 行 查询 。 

@ RESTRICTED: 这 种 模式 下 聚集 可 以 在 并 行 模式 中 执行 ， 但 是 只 限于 在 并 行 分 

组 领导 者 中 执行 。 

@ SAFE: 提供 了 对 并 行 查询 的 完全 支持 。 

如 果 把 一 个 函数 标记 为 SAFE， 必 须 记 住 该 函数 不 能 有 副作用 ， 执 行 顺 序 不 能 对 查询 
的 结果 造成 影响 。 只 有 这 样 ，PostgreSQL 才 应 该 被 允许 并 行 执行 操作 。 无 副作用 的 函数 
的 例子 有 sin(x)、length(s) 等 。IMMUTABLE 函数 是 很 好 的 候选 ， 因 为 它们 被 保证 对 给 定 
的 相同 输入 返回 相同 的 结果 。 如 果 应 用 某 种 限制 ，STABLE 函数 可 以 并 行使 用 。 


4.5.3 ”改进 效率 
到 目前 为 止 ， 所 定义 的 聚集 功能 已 经 很 强大 。 但 是 ， 如 果 使 用 滑动 窗口 ， 函 数 调用 
的 数量 就 会 爆炸 性 地 增长 。 从 下 面 这 个 例子 可 以 看 出 : 


test=# SELECT taxi price(x::numeric) 
OVER ( ROWS BETWEEN 0 FOLLOWING AND 3 FOLLOWING) 
FROM generate series(1l, 5) AS x; 
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NOTICE : intermediate: 2.5, per row: 1 
NOTICE: intermediate: 4.7, per row: 2 
NOTICE: intermediate: 9.1, per row: 3 
NOTICE: intermediate: 15.7, per row: 4 
NOTICE: intermediate: 2.5, per row: 2 
NOTICE: intermediate: 6.9, per row: 3 
NOTICE: intermediate: 13.5, per row: 4 
NOTICE: intermediate: 22.3, per row: 5 


对 于 每 一 行 ，PostgreSQL 都 将 处 理 整个 窗口 。 如 果 滑 动 窗口 很 大 ， 效 率 将 会 每 况 愈 
下 。 为 了 解决 这 一 问题 ， 可 以 扩展 我 们 的 聚集 。 在 此 之 前 还 是 要 删除 掉 旧 的 聚集 : 


DROP AGGREGATE taxi price(numeric); 
基本 上 需要 两 个 函数 ，msfunc 函数 将 把 窗口 中 的 下 一 行 加 入 中 间 结 果 上 


CREATE FUNCTION taxi msfunc (numeric，numeric) 
RETURNS numeric AS 
$$ 
BEGIN 
RAISE NOTICE "taxi msfunc called with $ and %', $1, $2; 
RETURN $1 + $2; 
END; 
$$ LANGUAGE ‘plpgsql' STRICT; 


minvfunc 函数 将 从 中 间 结 果 中 去 掉 刚 移出 窗口 之 外 的 值 : 


CREATE FUNCTION taxi minvfunc (numeric, numeric) 
RETURNS numeric AS 
$$ 
BEGIN 
RAISE NOTICE 'taxi minvfunc called with $ and %', $1, $2; 
RETURN $1 - $2; 
END; 
$$ LANGUAGE ‘plpgsql' STRICT; 


在 笔者 的 例子 中 用 的 是 加 和 减 。 在 更 加 精致 的 例子 中 ， 这 种 计算 可 能 是 任意 的 复 
一 个 语句 展示 了 如 何 重建 聚集 :; 


CREATE AGGREGATE taxi price (numeric) 
( 








INITCOND = 0, 
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STYPE = numeric, 


SFUNC = taxi per line, 

MSFUNC = taxi msfunc, 

MINVEFUNC = taxi minvfunc, 

MSTYPE = numeric 
); 
现在 让 我 们 再 次 运行 同一 个 查询 : 
test# SELECT taxi price(x::numeric) 

OVER (ROWS BETWEEN 0 FOLLOWING AND 3 FOLLOWING) 
FROM generate series(1l, 5) AS x; 
NOTICE: taxi msfunc called with 1 and 2 
NOTICE: taxi msfunc called with 3 and 3 
NOTICE: taxi msfunc called with 6 and 4 
NOTICE: taxi minfunc called with 10 and 1 
NOTICE: taxi msfunc called with 9 and 5 
NOTICE: taxi minfunc called with 14 and 2 
NOTICE: taxi minfunc called with 12 and 3 
NOTICE: taxi minfunc called with 9 and 4 


函数 调用 的 数量 已 经 急剧 下 降 。 对 每 一 行 只 有 固定 的 几 次 调用 需要 被 执行 ， 这 种 情 
况 下 已 经 不 再 需要 一 次 又 一 次 地 重复 计算 同一 个 帧 了 。 


4.5.4 ”编写 假想 聚集 


编写 聚集 并 不 难 ， 并 且 它 对 于 执行 更 加 复杂 的 操作 很 有 好 处 。 本 节 的 计划 是 编写 一 
个 假想 聚集 ， 其 概念 已 经 在 本 章 中 讨论 过 。 

实现 假想 聚集 与 编写 普通 聚集 没什么 太 多 不 同 ， 真 正 难 的 部 分 是 找 出 何 时 真正 需要 
用 到 它 。 为 了 尽 可 能 让 本 节 容 易 理解 ， 笔 者 决定 包括 一 个 小 例子 : 给 定 一 个 特定 的 顺 
序 ， 如 果 我 们 把 abc 添加 到 字符 串 的 尾部 结果 会 是 什么 ? 

下 面 是 实现 : 


CREATE AGGREGATE name ([[argmode] [argname] arg data type [, ... ]] 
ORDER BY [ argmode ] [ argname ] arg data type 





EL 
SFUNC = sfunc, 
STYPE = state data type 
[ , SSPACE = state data size ] 
[ , FINALFUNC = ffunc ] 
[ , FINALFUNC EXTRA ] 
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[ , INITCOND = initial condition ] 
[ , PARALLEL = { SAFE | RESTRICTED | UNSAFE } ] 
[ ,， HYPOTHETICAL ] 


需要 两 个 函数 。sfunc 函数 会 为 每 一 行 调用 : 


CREATE FUNCTION hypo sfunc(text, text) 
RETURNS text AS 
$$ 
BEGIN 
RAISE NOTICE "hypo_sfunc called with % and %', $1, $2; 
RETURN $1 || $2; 
END; 
$$ LANGUAGE ‘plpgsql'; 


两 个 参数 将 被 传递 给 这 个 过 程 ， 其 逻辑 和 之 前 相同 。 和 先前 类 似 ， 可 以 定义 一 个 
final 函数 调用 : 


CREATE FUNCTION hypo final (text, text, text) 
RETURNS text AS 
$$ 
BEGIN 
RAISE NOTICE 'hypo final called with %, %, and %', 
只 
RETURN $1 || $2; 
END; 
$$ LANGUAGE ‘'plpgsql'; 


一 旦 这 些 函 数 就 位 就 可 以 创建 假想 聚集 : 


CREATE AGGREGATE whatif (text ORDER BY text) ( 
INITCOND = 'START', 
STYPE = text, 
SFUNC = hypo sfunc, 
FINALFUNC = hypo final, 
FINALFUNC EXTRA = true, 
HYPOTHETICAL 
Ne 


注意 ， 这 个 聚集 已 经 被 标记 为 HYPOTHETICAL， 因 此 PostgreSQL 将 会 知道 它 实 际 
是 一 种 什么 样 的 聚集 。 
创建 好 聚集 后 ， 就 可 以 运行 它 : 
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test=# SELECT whatif('abc'::text) WITHIN GROUP (ORDER BY id::text) 
FROM generate series(1, 3) RS id; 
NOTICE: hypo sfunc called with START and 1 
NOTICE: hypo sfunc called with START1 and 2 
NOTICE: hypo sfunc called with START12 and 3 
NOTICE: hypo final called with START123, abc, and <NULL> 
whatif 


START123abc 
(1 row) 


理解 所 有 那些 聚集 的 关键 实际 上 在 于 充分 地 观察 何 时 何 种 类 型 的 函数 会 被 调用 ， 以 
及 总 体 机 制 如 何 工作 。 


在 本 章 中 ， 读 者 学 到 了 SQL 提供 的 高 级 特性 。 在 简单 聚集 之 上 PostgreSQL 提供 了 有 
序 集 、 分 组 集 、 窗 口 函 数 、 递 归 以 及 创建 自 定义 聚集 的 接口 。 在 数据 库 中 运行 聚集 的 好 
处 是 代码 容易 编写 并 且 数 据 库 引 擎 通常 有 效率 优势 。 

在 第 5 章 中 ， 我 们 将 把 注意 力 转向 更 多 管理 任务 上 ， 例 如 处 理 日 志 、 理 解 系统 统计 
售 息 以 及 实现 监控 。 


第 5 章 日 志文 件 和 系统 统计 信息 


在 第 4 章 ， 读 者 从 一 个 不 同 的 角度 学 到 了 很 多 有 关 高 级 SQL 的 知识 和 理解 SQL 的 方 
法 。 不 过 ， 数 据 库 工作 并 不 只 是 设计 奇特 的 SQL， 有 时 候 数 据 库 工 作 也 涉及 保持 数据 库 
以 专业 的 方式 运行 。 要 做 到 这 一 点 ， 非 常 重要 的 是 密切 关注 系统 统计 信息 、 日 志文 件 等 
等 。 监 控 是 专业 地 运行 数据 库 的 关键 。 

在 本 章 ， 读 者 将 会 学 到 以 下 主题 : 

@ ”收集 运行 时 统计 信息 。 

@ ”创建 日 志文 件 。 

@ ”收集 重要 信息 。 

@ 理解 数据 库 统计 信息 。 


5.1 收集 运行 时 统计 信息 





读者 一 定 要 学 会 的 第 一 点 是 使 用 和 理解 PostgreSQL 已 经 提供 的 内 建 统计 信息 。 正 如 笔 
者 一 直 在 讲 的 ， 如 果 不 首先 收集 数据 来 做 出 精明 的 决定 ， 就 没有 办 法 改进 性 能 和 可 靠 性 。 

本 节 将 指引 读者 了 解 PostgreSQL 的 运行 时 统计 信息 并 且 详 细 解释 如 何 从 数据 库 设 置 
中 提取 更 多 数据 。 

@ ”使 用 PostgreSQL 系统 视图 

PostgreSQL 提供 了 一 大 堆 系 统 视图 ， 它 们 让 管理 员 和 开发 者 之 类 的 人 可 以 深入 地 审 
视 系统 中 究竟 在 做 什么 。 其 问题 在 于 ， 很 多 人 实际 上 收集 了 所 有 这 类 数据 ， 但 却 无 法 真 
正 理 解 它 。 通 常 来 说 : 对 无 法 理解 的 东西 绘制 图 表 是 毫 无 意义 的 。 因 此 ， 本 节 的 目标 是 
讲 清 楚 PostgreSQL 必须 提供 哪些 东西 ， 以 期 能 让 人 们 充分 利用 它们 为 自己 的 工作 服务 。 

1.。 检 查实 时 流量 

每 当 笔者 检查 一 个 系统 时 ， 在 进一步 深究 之 前 ， 笔 者 总 是 首先 会 检查 一 个 系统 视 
图 。 当 然 ， 笔 者 说 的 就 是 pg_stat_activity。 该 视图 的 思想 就 是 让 用 户 有 机 会 弄 明 白 现在 正 
在 发 生 些 什么 。 

下 面 是 该 视图 的 结构 : 
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test=# \d pg stat activity 


Column Type 

datid oid 

datname name 

pid integer 
usesysid oid 

usename name 
application name text 

client addr inet 

client hostname text 

client port integer 

backend start timestamp with time 


xact start 
query_ start 
state_ change 
wait event type 
wait event 


state 
backend 
backend 


query 


View "pg catalog.pg stat activity" 


timestamp with time 
timestamp with time 
timestamp with time 
text 
text 
Etext 
xid xid 
xid 
text 


xmin 


= 


zone 
zone 
zone 
zone 


在 pg_stat_activity 将 为 用 户 提供 的 数据 中 ， 每 个 活动 连接 都 有 一 行 。 用 户 将 会 看 到 数 
据 库 的 内 部 对 象 ID (datid)、 被 某 人 连接 的 数据 库 名 称 以 及 服务 于 这 个 连接 的 进程 ID 


ne 


(pid)。 在 此 之 上 ，PostgreSQL 还 将 告诉 用 户 谁 在 连接 (usename， 注 意 其 中 少 了 


以 及 该 用 户 的 内 部 对 象 ID (usesysid)。 
其 中 还 有 一 个 名 为 application_name 的 域 值得 多 说 几 句 。 通 常 ，application_name 可 以 














最 终 用 户 自由 地 设置 : 


test=# SET application name TO ‘postgresql-support.de'; 


SET 


test=# SHOW application name ; 


application name 


postgresql-support .de 


(1 row) 





其 关键 在 了 


定 连 接 现在 实际 在 做 什么 ? 管理 员 不 可 能 赁 记忆 知道 所 有 的 SQL。 如 果 客 户 端 角 


FF ， 假 定 有 数 千 个 连接 来 自 于 一 个 卫 ， 作 为 一 个 管理 员 是 否 能 知道 一 个 特 


善意 


地 
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设置 application_ name 参数 ， 就 能 更 容易 地 理解 一 个 连接 的 真正 目的 。 在 笔者 的 例子 中 ， 
笔者 将 这 一 名 称 设 置 在 连接 所 属 的 域 。 这 使 得 查找 相似 的 连接 更 容易 ， 因 为 相似 的 操作 
也 会 导致 类 似 的 问题 。 

接 下 来 的 3 个 列 (client ) 将 告诉 用 户 一 个 连接 来 自 何方 。PostgreSQL 将 显示 了 P 地 
址 甚至 (如 果 被 配置 ) 主机 名 。 

backend_start 将 会 告诉 用 户 一 个 特定 连接 何 时 被 启动 。xact_start 表示 一 个 事务 何 时 被 
启动 。 接 着 还 有 query_start 和 state_change。 在 “黑暗 ”的 旧时 代 ，PostgreSQL 只 会 显示 
活动 查询 。 在 那个 时 期 查询 运行 时 间 比 现 如 今 更 长 ， 这 当然 说 得 通 。 在 现代 硬件 上 ， 
OLTP 查询 可 能 只 会 消耗 不 到 一 毫秒 ， 因 此 很 难 捕捉 到 可 能 做 了 坏事 的 查询 。 其 解决 方案 
是 既 显示 活动 查询 又 显示 正 查看 的 连接 之 前 执行 的 查询 。 

用 户 可 能 会 看 到 这 样 的 数据 : 

test=# SELECT pid, query start, state change, state, query FROM 

pg stat activity; 





EEORDE 
28001 

20E6=14=05 1020335757559310d 

2016=11=05 10:03:57.575595+01 

active 

SELECT pg_sleep(10000000); 


pid 

query_ start 
state_change 
State 

query 


在 这 种 情况 下 ， 用 户 可 以 看 到 在 第 二 个 连接 中 正在 执行 pg_sleep。 
一 旦 这 个 查询 被 中 止 ， 输 出 将 会 改变 : 


-[ RECORD 2 -一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 


28001 

20E6=41=050 10:03575 575593104 
2016=11=05 10:05:10.388522+01 
idle 

SELECT pg_sleep(10000000); 


pid 
query start 
state_ change 
state 
query 
该 查询 现在 被 标记 为 idle。state_change 和 query_start 之 间 的 差 是 该 查询 执行 所 需 的 
时 间 。 
姑 此 ，pg_stat_activity 让 用 户 对 当前 系统 正在 做 什么 有 一 个 大 体 上 的 认识 。 新 的 
state_change 域 让 我 们 更 有 可 能 找 出 开销 巨大 的 查询 。 
岗 在 的 问题 是 ， 一 旦 找到 了 不 好 的 查询 ， 如 何 能 真正 除去 它们 ?PostgreSQL 提供 了 两 
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个 函数 来 处 理 这 些 事情 : pg_cancel backend 和 pg terminate backend。pg cancel backend 函 
数 将 中 止 查询 但 是 把 连接 留 在 原 地 。pg terminate backend 函数 更 加 激进 一 些 ， 它 将 把 查 
询 和 整个 数据 库 连 接 全 都 清除 。 

如 果 用 户 想 要 断 开 除 自 己 之 外 所 有 其 他 用 户 的 连接 ， 可 以 这 样 做 : 

test=# SELECT pg terminate backend (pid) FROM pg stat activity WHERE pid <> 

pg backend pid(); 


pg terminate backend 


(2 row) 
如 果 用 户 正好 被 踢 出 了 系统 ， 将 会 显示 下 列 消息 : 


test=# SELECT pg_sleep (10000000) 7 
FATAL: terminating connection due to administrator command 
server closed the connection unexpectedly 
This probably means the server terminated abnormally 
before or while processing the request. 
The connection to the server was lost. Attempting reset: Succeeded. 


的 只 有 psql 会 尝试 重新 连接 。 对 于 大 部 分 其 他 客户 端 来 说 不 是 这 样 ， 特 别 是 
客户 端 库 不 会 尝试 重新 连接 


2. 检查 数据 库 
在 检查 了 活动 数据 库 连 接 之 后 ， 就 可 以 开始 更 进一步 检查 数据 库 层面 的 统计 信息 。 


pg_stat_database 将 对 PostgreSQL 实例 中 的 每 个 数据 库 返 回 一 行 。 
在 其 中 可 以 看 到 这 些 : 


test=# \d pg stat database 
View "pg catalog.pg_ stat database" 


Column | Type 1 Modifiers 
Se ee ee Ne de ee 

datid | oid 1 
datname | name 

numbackends | integer 1 
xact commit | bigint 1 
xact rollback | bigint 1 
blks_read | bigint 1 
和 由 | bigint 1 
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tup_returned bigint 1 
tup_fetched bigint 1 
tup inserted bigint 1 
tup updated bigint 1 
tup deleted | bigint 1 
conflicts bigint 1 
temp files bigint 1 
temp bytes | bigint 1 
deadlocks bigint 1 
blk read time double precision 1 
blk write time | double precision 1 
stats_reset timestamp with time zone | 
紧 接着 数据 库 ID 和 数据 库 名 称 是 一 个 名 为 numbackends 的 列 ， 它 显示 当前 打开 的 数 
据 库 连接 数 。 


然后 是 xact_commit 和 xact_rollback， 它 们 表示 应 用 是 否 在 提交 或 回 深 。blks_hit 和 
blks_read 会 告诉 用 户 缓 冲 命中 和 缓冲 未 命中 的 计数 。 在 检查 这 两 列 时 ， 记 住 我 们 主要 在 
讨论 共享 缓冲 区 命中 和 共享 缓冲 区 未 命中 。 在 数据 库 层面 上 没有 合理 的 方法 能 区 分 出 文 
件 系统 的 缓冲 命中 以 及 实际 的 磁盘 命中 。 在 Cybertec (www.postgresql-support.de )， 我 们 
喜欢 把 磁盘 等 待 和 pg_stat_database 中 的 缓冲 未 命中 关联 在 一 起 研究 系统 中 究竟 在 做 什么 。 

tup_ 列 将 告诉 用 户 系统 中 是 否 正在 进行 大 量 的 读 或 者 大 量 的 写 。 
接 下 来 还 有 temp_files 和 temp_bytes。 这 两 列 的 信息 惊人 的 重要 ， 因 为 它们 将 告诉 用 
户 其 数据 库 是 否 不 得 不 在 磁盘 上 写 入 临时 文件 ， 这 将 不 可 避免 地 拖 慢 操 作 。 临 时 文件 使 
用 量 大 的 原因 可 能 是 什么 ? 主要 原因 如 下 。 
@ 过 低 的 设置 : 如 果 work mem 设置 太 低 ， 就 没有 办 法 在 RAM 中 做 任何 事情 ， 因 
此 PostgreSQL 将 利用 磁盘 。 

@ 愚蠢 的 操作 : 经 常会 有 人 用 相当 昂贵 但 又 毫 无 意义 的 查询 来 折磨 他 们 的 系统 。 
如 果 在 一 个 OLTP 系统 上 看 到 很 多 临时 文件 ， 可 以 考虑 检查 一 下 昂贵 的 查询 。 

@ 索引 和 其 他 管理 任务 : 有时， 人们 可 能 会 创建 索引 或 者 运行 DDL。 这 些 操 作 可 
能 会 导致 临时 文件 IJO， 但 〈 在 很 多 情况 下 ) 不 一 定 是 问题 。 

简 而 言 之 ， 即 便 系 统 运 行 得 很 好 也 可 能 出 现 临 时 文件 。 但 是 ， 注 意 关 注 临 时 文件 并 
且 确 保 不 会 过 于 频繁 地 需要 临时 文件 绝对 是 有 意义 的 。 

最 后 还 有 两 个 更 加 重要 的 域 : blk read time 和 blk write time。 默 认 情况 下 ， 这 两 个 
域 是 空 的 并 且 不 会 有 数据 被 收集 。 它 们 的 意图 是 让 用 户 有 办 法 能 查看 在 WO 上 花费 了 多 少 
时 间 。 这 两 个 域 为 空 的 原因 是 参数 track io timing 默认 被 关闭 。 这 样 做 是 有 道理 的 ， 想 象 
一 下 用 户 想 要 检查 读 取 1000000 块 需要 多 久 。 要 做 到 这 一 点 ， 需 要 调用 C 库 中 的 time 函 
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数 两 次 ， 这 样 为 了 读 取 8GB 数据 就 需要 2000000 次 额外 的 函数 调用 。 这 是 否 将 导致 很 多 
开销 完全 取决 于 用 户 系统 的 速度 。 
幸运 的 是 ， 有 一 个 工具 能 帮助 用 户 判 断 计 时 工作 有 多 昂贵 : 


[hs@zenbook ~]$ pg test timing 





Testing timing overhead for 3 seconds. 
Per loop time including overhead: 23.16 nsec 
Histogram of timing durations: 


< usec $$ of total count 
出 97.70300 126549189 

空 2.29506 2972668 

4 0.00024 Ez} 

8 0.00008 101 

16 0.00160 2072 
S32 0.00000 5 
64 0.00000 6 
128 0.00000 4 
256 0.00000 0 
slp 0.00000 0 
1024 0.00000 4 
2048 0.00000 攻 


在 笔者 的 情况 中 ， 为 一 个 会 话 或 者 在 postgresql.conf 文件 中 将 track io_timing 打开 的 
开销 大 约 是 23 纳 秒 ， 这 还 算 可 以 。 专 业 的 高 端 服务 器 可 以 提供 的 数字 低 至 14 纳 秒 ， 而 
虚拟 化 的 服务 器 可 能 会 返回 高 达 1400 纳 秒 甚至 1900 纳 秒 的 值 ， 那 就 真 的 很 差 了 。 在 遇 
见 了 四 位 数值 的 情况 下 ， 度 量 IO 计时 无 疑 会 导致 可 察觉 的 开销 ， 这 将 会 拖 慢 系统 。 通 常 
的 规则 是 ， 在 真实 硬件 上 ， 计 时 不 是 问题 ， 在 虚拟 系统 上 ， 在 打开 之 前 先 检查 一 下 。 

的 也 可 以 使 用 ALTER DATABASE、ALTER USER 之 类 的 语句 有 选择 地 打开 
计时 


一 旦 用 户 已 经 获得 了 其 数据 库 中 正在 做 什么 的 总 体 情况 后 ， 接 下 来 的 想法 就 是 深入 
地 查看 各 个 表 上 的 活动 。 这 里 有 两 个 系统 视图 可 以 帮 到 我 们 : pg _stat_user tables 和 
pg_statio_user_tables。 下 面 是 第 一 个 : 





test=# \d pg_stat user tables 
View "pg_catalog.pg stat user tables" 
Column 1 Type 
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relname name 

seq_scan bigint 
seq tup read bigint 
idx scan bigint 
idx tup fetch bigint 
n tup ins bigint 
n tup upd bigint 
n tup del bigint 
n_ tup hot upd bigint 
n live tup bigint 
n mod since analyze bigint 


last vacuum timestamp with time zone 
timestamp with time zone 
timestamp with time zone 


timestamp with time zone 


last autovacuum 
last analyze 
last autoanalyze 





1 
1 
1 
1 
1 
1 
1 
1 
1 
1 
n_dead tup | bigint 
1 
1 
1 
1 
1 
1 
1 
1 
1 


vacuum count bigint 
autovacuum count bigint 
analyze count bigint 
autoanalyze_count bigint 


在 笔者 看 来 ，pg_stat_user_tables 是 最 重要 的 系统 视图 之 一 ， 但 也 是 最 容易 被 误解 其 
至 被 忽视 的 系统 视图 之 一 。 笔 者 觉得 很 多 人 虽然 看 过 它 却 无 法 充分 发 挥 其 潜力 。 如 果 使 
用 得 当 ，pg_stat_user_tables 在 一 些 情况 下 简直 是 一 部 启示 录 。 

在 我 们 深入 解释 数据 之 前 ， 重 点 得 理解 实际 有 哪些 域 。 首 先 ， 对 每 个 表 都 有 一 项 ， 
它 表 明 发 生 在 该 表 上 的 顺序 扫描 的 次 数 〈seq_scan)。 然 后 还 有 seq_tup_read， 它 告诉 我 们 
在 那些 顺序 扫描 时 系统 读 取 了 多 少 个 元 组 。 


&9 记 住 seq_tup read 列 ， 它 包含 至 关 重 要 的 信息 ， 能 够 帮助 发 现 性 能 问题 。 











idx_ scan 是 列表 上 的 下 一 个 ， 它 会 向 我 们 展示 多 长 时 间 为 这 个 表 使 用 一 次 索引 。 
PostgreSQL 还 将 展示 哪些 查询 返回 了 多 少 行 。 然 后 还 有 一 些 以 n_tup 开头 的 列 ， 它 们 会 
告诉 我 们 插入 、 更 新 以 及 删除 了 多 少 。 这 里 最 重要 的 事情 与 HOT UPDATE 有 关 。 在 运行 
一 个 UPDATE 时 ，PostgreSQL 必须 复制 一 行 以 确保 ROLLBACK 能 正确 地 工作 。HOT 
UPDAIE 的 好 处 在 于 它 人 允许 PostgreSQL 确保 一 行 不 需要 离开 一 个 块 。 行 的 备份 也 留 在 同 
一 块 中 ， 这 样 通常 对 性 能 有 利 。 适 当 数量 的 HOT UPDATE 表示 用 户 在 UPDATE 比较 强烈 
的 负载 下 走 在 正确 的 轨道 上 。 虽 然 这 里 很 难 对 所 有 的 用 例 给 出 普通 更 新 和 HOT UPDATE 
之 间 的 完美 比例 ， 但 人 们 实际 上 已 经 开始 思考 ， 什 么 样 的 负载 能 从 很 多 就 地 操作 中 获 
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益 。 通 常 来 说 ， 负 载 中 UPDATE 的 强度 越 高 ， 有 很 多 HOT UPDATE 子 句 就 会 更 好 。 
最 后 还 有 一 些 VACUUM 统计 信息 ， 其 含义 大 部 分 都 不 言 而 喻 。 


3， 理解 pg_stat_user_tables 


阅读 所 有 这 类 数据 可 能 会 很 有 趣 ， 但 是 如 果 无 法 理解 它 ， 就 会 发 现 它 其 实 相 当 无 
聊 。 一 种 使 用 pg_stat_user_tables 的 方法 是 检测 哪些 表 可 能 需要 索引 。 一 种 找到 正确 方向 
线索 的 方法 是 使 用 下 面 的 查询 ， 它 已 经 为 笔者 服务 了 多 年 : 

SELECT schemaname, relname, 

seq scan, 

seq tup read, 

seq tup read / seq scan AS avg, 
idx scan 

FROM pg stat user tables 

WHERE seq scan > 0 

ORDER BY seq tup read 

DESC LIMIT 25; 


其 思想 是 找 出 大 型 的 表 ， 它 们 被 顺序 扫描 频繁 地 使 用 。 那 些 表 自然 会 出 现在 列表 的 
顶部 ， 它 们 会 给 出 非常 高 的 seq_tup_read 值 ， 能 找到 这 样 的 表 实 在 让 人 很 兴奋 。 
从 上 至 下 观察 结果 并 寻找 昂贵 的 扫描 。 记 住 顺序 扫描 不 一 定 是 不 好 的 ， 在 
PP 备份 、 分 析 语 句 中 很 自然 地 会 出 现 顺 序 扫 描 ， 因 此 也 不 会 造成 任何 损害 。 不 
过 ， 如 果 总 是 在 运行 大 型 的 顺序 扫描 ， 系 统 的 性 能 将 会 每 况 愈 下 。 


注意 这 个 查询 的 价值 就 像 黄 金 一 般 一 一 它 将 帮助 用 户 找 出 缺少 索引 的 表 。 近 二 十 年 
的 实践 经 验 已 经 一 次 又 一 次 地 证 明 缺少 索引 是 糟糕 性 能 最 重要 的 原因 ， 因 此 读者 看 到 的 
这 个 查询 可 以 说 就 是 一 块 金子 。 

一 旦 用 户 已 经 找到 了 可 能 缺失 的 索引 ， 可 以 考虑 简要 地 看 看 表 的 缓冲 行为 。 
pg_statio_user tables 将 包含 关于 各 种 东西 的 信息 ， 例 如 表 (heap blks )、 索 引 
(idx_blks ) 以 及 超 尺寸 属性 存储 技术 (TOAST) 表 的 缓冲 行为 。 最 后 用 户 能 发 现 更 多 有 
关 TID 扫描 的 信息 ， 但 这 通常 与 系统 的 总 体 性 能 无 关 : 

test=# \d pg_statio_user tables 


View "pg catalog.pg statio user tables" 


Column | Type Modifiers 
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relname name 

heap blks read bigint 
heap blks hit bigint 
idx blks read bigint 


1 1 
1 1 
1 1 
1 1 
idx blks hit | bigint | 
1 1 
1 1 
1 1 
1 1 


toast blks read | bigint 
toast blks hit bigint 
tidx blks_ read bigint 
tidx blks hit bigint 


尽管 pg_statio_user_tables 包含 重要 的 信息 ， 但 通常 的 情况 是 pg_stat_user_tables 更 可 
能 会 为 用 户 提供 真正 相关 的 观察 〈 例 如 缺失 索引 等 )。 

4. 深入 研究 索引 

虽然 pg_stat_user tables 对 找 出 缺失 的 索引 很 重要 ， 但 有 时 有 必要 找 出 本 不 应 存在 的 
索引 。 最 近 ， 笔 者 因 公 去 了 德国 一 趟 ， 过 程 中 发 现 一 个 系统 中 包含 的 大 部 分 是 毫 无 意义 
的 索引 《〈 占 总 存储 消耗 的 74%)。 虽 然 在 数据 库 不 大 的 情况 下 这 可 能 并 不 是 问题 ， 但 在 大 
型 系统 的 情况 下 就 不 同 了 一 一 数 百 GB 无 意义 的 索引 可 能 会 严重 伤害 总 体 性 能 。 

可 以 检查 pg _stat_user indexes 来 找 出 那些 无 意义 的 索引 : 


test=# \d pg stat user indexes 





View "pg catalog.pg stat user indexes" 


Column | Type | Modifiers 
EE EE YN 
relid | oid 1 
indexrelid | oid 
schemaname | name 
relname | name 1 
indexrelname | name 1 
idx scan | bigint | 
idx tup read | bigint | 
idx tup fetch | bigint | 





该 视图 告诉 我 们 ， 对 于 每 个 方案 中 每 个 表 上 的 每 个 索引 ， 多 久 会 使 用 它 一 次 
(idx_scan)。 为 了 让 这 个 视图 丰富 一 点 ， 笔 者 建议 用 下 面 的 SQL: 


SELECT schemaname, 
relname, 














indexrelname, 
idx scan, 
pg_size pretty(pg relation size(indexrelid)), 
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pg_ size pretty(sum(pg relation size(indexrelid)) 
OVER (ORDER BY idx scan, indexrelid)) AS total 
FROM pg stat user indexes 
ORDER BY 6 : 


这 个 语句 的 输出 非常 有 用 ， 它 不 仅 包含 有 关 一 个 索引 多 久 被 使 用 一 次 的 信息 一 一 它 
还 告诉 我 们 为 每 个 索引 浪费 了 多 少 空间 。 最 后 ， 这 个 语句 在 列 6 中 加 上 了 所 有 的 空间 消 
耗 。 用 户 现 在 可 以 仔细 检查 该 表 并 且 重 新 思考 所 有 那些 很 少 被 使 用 的 索引 。 关 于 何 时 删 
除 一 个 索引 很 难 给 出 一 个 通用 规则 ， 因 此 一 些 手工 检查 会 更 有 意义 。 


不 要 只 是 育 目 地 删除 索引 。 在 一 些 情况 下 ， 索 引 未 被 使 用 只 是 因为 使 用 应 
人 用 的 最 终 用 户 与 预期 不 同 而 已 。 在 最 终 用 户 改 变 的 情况 下 ( 雇佣 了 一 名 新 的 秘 
书 等 )， 一 个 索引 可 能 又 会 很 好 地 再 次 转变 成 有 用 的 对 象 。 
还 有 一 个 名 为 pg_statio_user_indexes 的 视图 ， 它 包含 有 关 索 引 的 缓冲 信息 。 尽 管 它 很 
有 趣 ， 但 它 通常 也 不 包含 能 导致 重大 改进 的 信息 。 
5。 跟踪 后 人 台 工 作者 
在 本 节 中 ， 是 时 候 看 看 后 台 写 入 器 的 统计 信息 了 。 如 你 所 知 ， 数 据 库 连接 在 很 多 情 
况 下 不 会 直接 写 块 到 磁盘 中 。 相 反 ， 数 据 由 后 台 写 入 器 进程 或 者 检查 点 进程 写 入 。 
要 看 看 数据 如 何 被 写 入 ， 可 以 检查 pg_stat_bgwriter 视图 : 


test=# \d pg_stat_bgwriter 
View "pg catalog.pg stat bgwriter" 


Column | Type Modifiers 
PE es 
checkpoints timed bigint 
checkpoints req bigint 


checkpoint write time 
checkpoint sync time 


double precision 
double precision 


buffers checkpoint bigint 
buffers_ clean bigint 
maxwritten clean bigint 
buffers backend bigint 
buffers backend fsync bigint 
buffers alloc bigint 


一 一 一 一 一 一 一 一 一 一 一 + 





stats reset 


这 里 首先 会 吸引 读者 注意 力 的 事情 是 前 两 列 。 在 本 书后 面 的 部 分 读者 会 学 到 
PostgreSQL 将 执行 定期 的 检查 点 ， 它 们 对 于 确保 数据 确实 被 写 到 磁盘 上 是 必需 的 。 如 果 


timestamp with time zone 
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户 的 检查 点 相互 之 间 离 得 太 近 ，checkpoint req 可 能 会 为 用 户 指 出 正确 的 方向 。 如 果 请 
求 的 检查 点 太 多 ， 可 能 意味 着 有 很 多 数据 被 写 入 并 且 检 查 点 总 是 因为 高 吞吐 而 被 触发 。 
除 此 之 外 ，PostgreSQL 将 告诉 用 户 一 个 检查 点 期 间 写 入 数据 所 花 的 时 间 以 及 同步 所 需 的 
时 间 。 还 有 ，buffers_checkpoint 指示 检查 点 期 间 有 多 少 缓冲 区 被 写 入 ， 以 及 有 多 少 是 被 
后 台 写 入 器 写 入 的 《buffers_clean)。 

maxwritten_clean 告诉 我 们 后 台 写 入 器 由 于 写 入 了 太 多 缓冲 区 停止 清理 扫描 的 次 数 。 

最 后 ， 还 有 buffers backend (由 后 端 数据 库 连接 直接 写 入 的 缓冲 区 数量 )、 
buffers_backend_ fsynce〔 一 个 数据 库 连 接 刷 写 的 缓冲 区 数量 ) 以 及 buffers_alloc， 它 包含 被 
分 配 的 缓冲 区 数量 。 


6， 跟 踪 、 归 档 以 及 流 


在 本 节 中 ， 我 们 将 看 到 一 些 复 制 和 事务 日 志 归档 相关 的 特性 。 第 一 项 要 检查 的 是 
pg_stat_archiver， 它 会 告诉 我 们 有 关 归 档 进程 的 信息 ， 归 档 进程 会 将 事务 日 志 (WAL) 从 
主 服务 器 移动 到 某 种 备份 设备 : 


test=# \d pg_stat archiver 


a 








View "pg_catalog.pg stat archiver" 


Column Type Modifiers 
archived count bigint 
last archived wal 


last archived time timestamp with time zone 
bigint 

Eext 

timestamp with time zone 


failed count 
last failed wal 
last failed time 
stats reset 


pg_stat_archiver 包含 有 关 归 档 进程 的 重要 信息 。 首 先 ， 它 会 报告 有 关 已 经 被 归档 的 事 
务 日 志文 件 的 数量 (archived_count)。 它 还 知道 最 后 一 个 被 归档 的 文件 以 及 何 时 被 归档 
(last_archived wal 和 last_achived time )。 

虽然 了 解 WAL 文件 的 数量 很 有 趣 ， 但 这 真 的 不 重要 。 因 此 可 以 考虑 看 一 看 failed_ 
count 和 last_failed_wal。 如 果 事 务 日 志 归 档 失败 ， 它 将 会 告诉 用 户 最 后 一 个 失败 的 文件 以 
及 是 何 时 发 生 。 推 荐 对 这 些 域 保持 关注 ， 因 为 不 这 样 做 就 可 能 出 现 归档 没有 工作 但 用 户 
却 没 有 得 到 通知 的 情况 。 

如 果 用 户 正在 运行 流 复制 ， 下 面 两 个 视图 就 对 用 户 非常 重要 。 第 一 个 名 为 pg_stat_ 
replication， 它 提供 有 关 从 主机 到 从 机 的 流 进程 的 信息 。 每 个 WAL 发 送 器 进程 都 有 一 项 
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ee 


timestamp with time zone 
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。 如 果 一 个 项 都 没有 ， 就 没有 事务 日 志 流 在 进行 ， 这 可 能 不 是 用 户 想 看 到 的 。 
让 我 们 看 看 pg_stat_replication: 


test=# \d pg stat replication 
View "pg catalog.pg stat replication" 


Column | Type | Modifiers 
ps Rs 
pid | integer 1 
usesysid | oid 1 
usename | name 1 
application name | text | 
client addr | inet 1 
client hostname | text 1 
client port | integer 1 
backend start | timestamp with time zone | 
backend xmin xd 1 
state | text | 
sent location | pg_lsn 1 
write location | pg lsn 1 
flush location | pg_lsn 1 
replay location | pg_1sn 1 
sync priority | integer 1 
sync_state Eext 1 








在 这 个 视图 中 将 能 找到 表示 流 复 制 连接 上 的 用 户 名 ， 然 后 还 有 一 个 应 用 名 与 连接 数 
据 (client ) 关联 在 一 起 。 接 着 ，PostgreSQL 将 告诉 我 们 流连 接 何 时 启动 。 在 生产 系统 
中 ， 一 个 年 轻 的 连接 可 能 表明 一 种 网 络 问题 甚至 更 坏 的 情况 〈 可 靠 性 问题 等 )。state 列 展 示 
流 的 其 他 端 处 于 哪 种 状态 。 注 意 在 第 10 章 中 将 会 有 更 多 有 关于 此 的 信息 。 

有 一 些 域 告诉 我 们 通过 网 络 连接 已 经 发 送 了 多 少 事务 日 志 (sent_location)、 向 内 核发 
送 了 多 少 事务 日 志 (write_location)、 有 多 少 被 刷 写 到 磁盘 (flush_location〉 以 及 有 多 少 
已 经 被 重 放 (replay_location)。 最 后 还 列 出 了 同步 状态 。 

pg_stat_replication 可 以 在 复制 设置 中 的 发 送 服 务 器 上 查询 ， 而 pg_stat_wal_receiver 则 
可 以 在 接收 端 被 参考 。 它 能 提供 类 似 的 信息 并 且 人 允许 在 复制 品 (或 是 类 似 的 地 方 ) 上 提 
取 这 些 信息 

这 里 是 该 北 视 图 的 定义 : 


test=# \d pg stat wal receiver 

















View "pg catalog.pg stat wal receiver" 
Column | Type | Modifiers 


pid 

status 
receive start 
receive start 
received lsn 
received tli 
last msg send 
last msg rece 
latest end Ls: 
latest end 七 il 
slot name 
conninfo 
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lsn 
下 二 


time 
ipt time 
n 
me 


integer 

text 

pg lsn 

integer 

pg lsn 

integer 

timestamp with time zone 
timestamp with time zone 
pg_lsn 

timestamp with time zone 
text 

text 





首先 ，PostgreSQL 告诉 我 们 WAL 接收 器 进程 的 ID， 然 后 该 视图 向 我 们 展示 了 使 用 
中 的 连接 状态 。receive_start_lsn 告诉 我 们 WAL 接收 器 被 启动 时 使 用 的 事务 日 志 位 置 。 
Teceive start ti 包含 WAL 接收 器 被 启动 时 在 使 用 的 时 间 线 。 在 某 一 时 刻 ， 用 户 可 能 想 要 
知道 最 后 的 WAL 位 置 及 时 间 线 。 要 得 到 这 两 个 数字 ， 可 使 用 received lsn 和 received tli。 

在 接 下 来 的 两 列 中 ， 有 两 个 时 间 戳 : last_msg_send time 和 last_ msg receipt_time。 它 
们 说 明 一 个 消息 何 时 被 发 送 以 及 被 收 到 。 

latest_end lsn 包含 在 latest_end time 时 报告 给 WAL 发 送 器 进程 的 最 后 一 个 事务 日 志 
位 置 。 最 后 ， 还 有 slot_name 和 连接 信息 的 一 个 含混 版 本 〈 安 全 相关 的 信息 被 隐 去 )。 


7. 检查 SSL 连接 


很 多 运行 PostgreSQL 的 人 使 用 SSL 来 加 密 从 服务 器 到 客户 端的 连接 。 近 期 版 本 的 
PostgreSQL 提供 了 一 个 视图 来 得 到 那些 加 密 连 接 的 概要 ， 它 就 是 pg_stat_ssl: 


test=# \d pg_s 














tat ssl 


View "pg_catalog.pg stat ssl" 


Column 1 


1 
ssl 1 
Version 
cipher 
bits 1 
compression | 

1 


clientdn 


Type 


integer 
boolean 
EextE 
text 
integer 
boolean 
text 





| Modifiers 
a 


每 一 个 进程 都 由 它 的 进程 ID 表示 。 如 果 一 个 连接 使 用 了 SSL， 则 第 二 个 列 被 设置 为 
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真 。 第 三 和 第 四 列 将 定义 版 本 以 及 密码 。 最 后 ， 还 有 加 密 算法 使 用 的 位 数 、 是 否 使 用 压 
缩 的 指示 器 以 及 来 自 客户 端 证 书 的 标识 名 (DN) 域 。 


8， 实 时 检查 事务 
到 目前 为 止 ， 我们 已 经 讨论 了 几 个 统计 信息 表 。 它 们 背后 的 想法 都 是 查看 整个 系统 中 


在 做 什么 。 但 是 如 果 用 户 是 一 个 想 要 观察 个 体 事务 的 开发 者 呢 ?”pg_stat_xact_user tables 能 
帮 上 忙 。 它 不 包含 系统 范围 的 事务 而 只 有 关于 当前 事务 的 数据 。 


test=# \d pg_ stat xact user tables 
View "pg catalog.pg stat xact user tables" 


Column | Type | Modifiers 

SS TR Ne se 
relid | oid 1 

schemaname | name 

relname | name | 
seq_scan | bigint | 
seq tup read | bigint | 
idx_scan | bigint | 
idx tup fetch | bigint | 
n tup ins | bigint | 
n tup upd | bigint | 
n tup del | bigint | 
1 


n tup hot upd | bigint 

因此 开发 者 可 以 在 事务 提交 前 查看 该 事务 ， 看 看 它 是 否 导致 了 性 能 问题 ， 这 样 有 助 
于 把 总 体 数据 与 由 用 户 应 用 导致 的 数据 区 分 开 来 。 

应 用 开发 者 使 用 这 个 视图 的 最 理想 方式 是 在 事务 提交 前 增加 一 个 函数 调用 在 应 用 中 ， 
跟踪 事务 做 了 什么 。 然 后 可 以 检查 这 些 数据 ， 把 当前 事务 的 输出 与 总 体 负载 区 分 开 。 


9， 跟 踪 清 理 进度 


在 PostgreSQL 9.6 中 ， 社 区 引入 了 一 个 很 多 人 一 直 在 期 待 的 系统 视图 。 很 多 年 来 ， 人 
们 都 想 要 跟踪 一 个 清理 进程 的 进度 ， 看 看 它 还 有 多 久 才能 做 完 。 
pg_stat_progress_vacuum 就 是 用 来 回答 这 类 问题 的 : 








test=# \d pg stat progress vacuum 

View "pg catalog.pg stat progress vacuum" 
Column | Type | Modifiers 

le EE 

pid | integer | 


datid 
datname 1 
relid 1 
phase 

heap blks total 
heap blks scanned 


heap blks vacuumed 
index vacuum count 
max dead tuples 
num dead tuples 





大 部 分 列 都 是 不 言 而 喻 的 ， 因 
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text 

bigint 
bigint 
bigint 
bigint 
bigint 
bigint 





此 笔者 也 不 再 袭 述 。 只 有 几 件 事情 需要 记 住 。 首 先 ， 





处 理 不 是 线性 的 一 一 它 可 能 会 比较 跳跃 。 此 外 ， 清 理 操 作 通 常 都 很 快 ， 因 此 进展 可 能 很 


迅速 并 且 难 于 跟踪 。 


10. 使 用 pg_stat_statements 


在 讨论 了 前 几 个 视图 之 后 ， 现 在 我 们 的 视线 该 转 回 到 最 重要 的 视图 上 ， 它 们 可 以 被 
用 来 找 出 性 能 问题 。 笔 者 说 的 当然 是 pg_stat_statements， 其 思想 是 获得 有 关系 统 上 查询 的 
信息 ， 它 可 以 帮助 找 出 哪 种 类 型 的 查询 很 慢 以 及 多 久 调 用 一 次 查询 。 


要 使 用 这 个 模块 ， 需 要 3 


步 : 











(1) 在 postgresql.conf 文 件 中 的 shared_preload libraries 内 加 上 pg_stat_statements 。 


(2) 重启 数据 库 服务 器 。 


(3) 在 选择 的 数据 库 中 运行 CREATE EXTENSION pg_stat_statements。 
让 我 们 看 看 该 视图 的 定义 : 


test=# \d pg_stat sta 


tements 


View "public.pg stat statements" 


Column 
userid 
dbid 
queryid 
query 
calls 
total time 
min time 
max time 
mean time 


stddev time 


bigint 
text 

bigint 
double 
double 
double 
double 
double 
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Type 


precision 
precision 
precision 
precision 
precision 





Modifiers 
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rows | bigint 
shared blks hit | bigint 
shared blks read | bigint 
shared blks dirtied | bigint 
shared blks written | bigint 
local blks hit | bigint 
local blks read | bigint 
local blks dirtied | bigint 
local blks written | bigint 
temp blks read | bigint 
temp blks written | bigint 
blk read time | double precision 
blk write time | double precision 


pg_stat_statements 提供 了 极 好 的 信息 。 对 于 每 个 数据 库 中 的 每 个 用 户 ， 它 为 每 个 查询 提 
供 一 行 。 默 认 情况 下 它 跟踪 5000〈 可 以 通过 设置 pg_stat_statements.max 来 更 改 ) 个 查询 。 


查询 和 参数 是 分 离 的 。PostgreSQL 将 会 在 查询 中 放置 占 位 符 ， 这 样 可 以 让 
9 只 是 使 用 不 同 参 数 的 相同 查询 被 聚集 起 来 。“SELECT .… FROM x WHERE y = 
10” 将 被 转变 成 “SELECT ... FROM x WHERE y=?” 


对 于 每 个 查询 ，PostgreSQL 会 告诉 我 们 它 已 经 消耗 的 总 时 间 以 及 调用 次 数 。 在 近期 
的 版 本 中 ， 增 加 了 min_time、max_time、mean time 和 stddev。 标 准 偏差 特别 值得 一 提 ， 
因为 它 将 告诉 我 们 一 个 查询 的 运行 时 间 是 稳定 的 还 是 波动 的 。 不 稳定 的 运行 时 间 可 能 
于 多 种 原因 发 生 : 

@ ”如 果 查 询 的 数据 没有 完全 被 缓存 在 RAM 中 ， 查 询 将 去 访问 磁盘 ， 它 们 将 比 数据 

被 缓存 时 花费 更 长 的 时 间 。 

@ 不同 的 参数 可 能 导致 不 同 的 计划 以 及 完全 不 同 的 结果 集 。 

@ ”并 发 和 锁 可 能 会 有 影响 。 

PostgreSQL 还 将 告诉 我 们 一 个 查询 的 缓冲 行为 。shared ”columns 列 展示 有 多 少 块 来 
自 于 缓存 (_hit) 或 者 来 自 于 操作 系统 (_read)。 如 果 很 多 块 来 自 于 操作 系统 ， 查 询 的 运 
行 时 间 可 能 会 波动 。 

接 下 来 的 一 批 列 都 与 本 地 缓冲 有 关 。 本 地 缓冲 是 由 数据 库 连接 直接 分 配 的 内 存 块 。 

在 所 有 这 些 信息 之 上 ，PostgreSQL 提供 了 有 关 临 时 文件 IO 的 信息 。 注 意 在 构建 大 型 
索引 或 者 执行 某 些 其 他 大 型 DDL 的 情况 下 ， 临 时 文件 IO 将 会 自然 地 发 生 。 不 过 ， 在 
OLIP 场景 下 临时 文件 通常 都 是 非常 不 好 的 东西 ， 因 为 它 可 能 造成 的 磁盘 阻塞 将 会 拖 慢 整 
个 系统 。 大 量 的 临时 文件 IO 可 能 表明 几 种 不 太 好 的 事情 。 下 面 的 列表 包含 了 笔者 心目 中 
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的 前 三 位 : 
@ 不良 的 work mem 设置 (OLTP) 。 
@ 次 优 的 maintenance_ work mem 设置 (DDL) 。 
@ 不 应 被 首先 运行 的 查询 。 
最 后 ， 有 两 个 域 包含 有 关 IO 计时 的 信息 。 默 认 情况 下 ， 这 两 个 域 为 空 。 其 原因 是 在 
某 些 系统 上 计时 可 能 本 身 就 会 带 来 很 多 开销 。 因 此 ，track io _timing 的 默认 值 是 假 一 一 如 
果 需 要 这 类 数据 记得 把 它 打开 。 
一 旦 该 模块 被 启用 ，PostgreSQL 就 开始 收集 数据 ， 并 且 用 户 就 可 以 使 用 这 个 视图 。 
绝 不 要 在 一 个 客户 面前 运行 “SELECT * FROM pg stat_statements"。 笔 者 
不 止 一 次 地 看 到 人 们 会 对 查询 指 指点 点 ， 他 们 碰巧 知道 查询 的 情况 ， 并 且 开 始 
解释 为 什么 会 这 样 、 谁 干 的 、 干 了 什么 、 什 么 时 候 干 的 等 。 在 使 用 这 个 视图 
时 ， 总 是 应 该 创建 一 个 排序 的 输出 ， 这 样 最 相关 的 信息 就 能 马上 被 看 见 。 


在 Cybertec， 我 们 已 经 发 现下 面 的 查询 非常 有 助 于 获得 数据 库 服 务 器 行为 的 总 览 : 


test=# SELECT round((100 * total time/sum(total time) OVER ())::numeric, 
2) percent, 








round (total time::numeric, 2) AS total, 
cHiLs, 
round (mean time::numeric, 2) AS mean, 
substring (query, 1, 40) 
FROM pg_stat statements 
ORDER BY total time DESC 
LIMIT 10; 
percent total | calls | mean substring 


54.47 i12891t E22161 0.9. UPDATE pgbench branches SET 
bbalance = b 
43.01 BRB L925 T22161 | 007 UPDATE pgbench tellers SET 
tbalance = tb 


1.46 2981506 1 122161 | 0.02 UPDATE pgbench accounts SET 
abalance = a 

0.50 POL9s830 E2216 | 00 SELECT abalance FROM 
pgbench accounts WH 

0.42 8562220 1 22161 | Om0¥ INSERT INTO pgbench history 
(tad blidy a 

0.04 85a63°| 1 1 3563 copy pgbench accounts from 


stdin 


0.02 44.11 1 EN Vacuum analyze pgbench accounts 
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间 ， 


人 OZ2 | A42:86 | 122161 | 0:00° END: 
0.02 | 34208 | 122171 | 000 | BEGIN; 
0.01 | 22.46 | 1 1 22.46 | alter table pgbench accounts 


add primary 
(10 rows) 
它 显示 排名 前 十 的 查询 及 其 运行 时 间 ， 包 括 比例 。 它 还 显示 该 查询 的 平均 执行 时 
这 样 用 户 可 以 决定 哪些 查询 的 运行 时 间 是 否 太 高 。 
用 户 可 以 用 自己 的 方式 检查 这 个 列表 并 且 观 察 所 有 看 起 来 平均 运行 时 间 过 长 的 查询 。 
记 住 检查 前 1000 个 查询 通常 并 不 划算 。 在 大 部 分 情况 下 ， 前 几 个 查询 就 已 经 对 应 了 





系统 上 的 大 部 分 负载 。 
OD 在 笔者 的 例子 中 ， 笔 者 使 用 了 一 个 子 串 来 把 查询 缩短 以 适合 页 面 。 如 果 想 
看 


用 ， 


到 实际 的 查询 语句 可 以 不 这 么 做 。 
记 住 pg_stat_statements 将 默认 把 查询 在 1024 字 节 处 切断 : 


test=# SHOW track activity query size; 
track activity query size 


可 以 考虑 把 这 个 值 增加 到 16384。 如 果 用 户 的 客户 端 运行 基于 Hibernate 的 Java 应 
一 个 较 大 的 track_activity_query_size 值 将 确保 查询 不 会 在 有 趣 的 部 分 被 显示 之 前 就 被 


切断 。 


笔者 想 在 这 里 指出 pg_stat_statements 到 底 有 多 重要 ， 它 是 目前 为 止 跟踪 到 性 能 问题 





的 最 容易 的 方式 。 一 个 慢 查 询 日 志 绝 对 不 如 pg_stat_statements 那么 有 用 ， 因 为 慢 查 询 日 
志 只 会 指出 个 别 的 慢 查 询 一 一 它 不 会 告诉 我 们 无 数 中 等 查询 导致 的 问题 。 因 此 ， 笔 者 推 





是 打开 这 个 模块 。 它 的 代价 其 实 很 小 并 且 不 会 伤害 系统 的 总 体 性 能 。 
默认 情况 下 ，PostgreSQL 会 跟踪 (从 9.6 版 本 起 ) 5000 种 查询 。 在 大 部 分 正常 合理 


的 应 用 中 ， 这 已 经 足够 。 





要 重 置 这 些 数据 ， 考 虑 使 用 下 面 的 指令 : 


test=# SELECT pg stat statements reset (); 
pg stat statements reset 
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5.2 创建 日 志文 件 


在 深入 地 看 过 了 PostgreSQL 提供 的 系统 视图 之 后 ， 现 在 可 以 来 配置 日 志 了 。 幸 运 的 
是 ，PostgreSQL 提供 了 简单 的 方式 来 使 用 日 志文 件 并 且 帮 助人 们 容易 地 设置 一 个 好 的 配 
置 。 收 集 日 志 很 重要 ， 因 为 它 能 指出 错误 和 潜在 的 数据 库 问题 。 

所 有 需要 的 参数 都 在 postgresql.conf 文件 中 。 

@ 配置 postgresql.conf 文 件 

本 节 将 介绍 postgresql.conf 文件 中 一 些 对 于 配置 日 志 最 重要 的 项 ， 以 及 如 何以 最 有 利 
的 方式 使 用 日 志 。 

在 开始 前 ， 笔 者 想 要 对 PostgreSQL 中 的 日 志 说 几 句 。 在 Unix 系统 上 ，PostgreSQL 默 
认 将 把 日 志 信息 发 送 到 stderr。 不 过 stderr 对 于 日 志 并 不 是 好 地 方 ， 因 为 用 户 肯 定 想 要 在 以 
后 的 某 一 时 刻 检查 日 志 流 。 因 此 ， 利 用 本 章 的 知识 根据 需要 进行 调整 就 会 非常 有 意义 。 


。 定 义 日 志 目 的 地 和 轮转 
让 我 们 先 扫 一 眼 postgresqlconf 文件 并 看 看 可 以 做 些 什么 : 




















# - Where to Log -— 


#1og_destination = "stderr' 
# Valid values are combinations of 
# stderr, csvlog, syslog, and eventlog, 
# depending on platform. csvlog 
# requires logging collector to be on. 


# This is used when logging to stderr: 

#logging collector = off 
# Enable capturing of stderr and csvlog 
# into log files. Required to be on for 
# csvlogs. 


# (change requires restart) 


第 一 个 配置 选项 定义 如 何 处 理 日 志 。 日 志 默 认 会 被 送 去 stderr (在 Unix 上 )。 在 
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Windows 上 ， 日 志 的 默认 去 向 是 eventlog，eventlog 是 Windows 自 带 的 处 理 日 志 的 工具 。 
目 户 可 以 选择 将 日 志 送 去 csvlog 或 者 syslog。 
如 果 用 户 想 要 创建 PostgreSQL 日 志文 件 ， 就 应 该 把 去 向 设置 为 stderr 并 且 打 开 日 志 
收集 器 ， 然 后 PostgreSQL 就 将 创建 日 志文 件 。 
现在 的 问题 是 ， 那 些 日 志文 件 的 名 称 是 什么 以 及 那些 文件 被 存储 在 什么 地 方 ? 
postgresql.conf 中 就 有 答案 : 


# These are only used if logging collector is on: 





所 














yp 


#1og directory = "pg log' 
# directory where log files are written, 
# can be absolute or relative to PGDATA 
#1og_filename = 'postgresql-%Y-%m-%d %H%SM%SS.]1og" 
# log file name pattern, 
# can include strftime() escapes 
log_directory 会 告诉 系统 在 哪里 存储 日 志 。 如 果 使 用 一 个 绝对 路 径 ， 用 户 可 以 明确 地 
配置 日 志 存在 哪里 。 如 果 更 想 让 日 志文 件 直接 出 现在 PostgreSQL 的 数据 中 ， 可 以 简单 地 
给 一 个 相对 路 径 。 其 优势 是 数据 目录 将 会 是 自 包含 的 ， 用 户 可 以 移动 它 而 没有 后 顾 之 忧 。 
下 一 步 ， 用 户 可 以 定义 PostgreSQL 要 使 用 的 文件 名 。PostgreSQL 在 这 一 点 上 非常 灵 
活 ， 人 允许 用 户 使 用 strftime 提供 的 所 有 快捷 方式 。 为 了 让 读者 对 这 一 特性 的 强大 有 些 印 
象 ， 笔 者 在 自己 的 平台 上 快速 统计 了 一 下 ， 结 果 显 示 strftime 提供 了 43 〈!) 种 占 位 符 来 
创建 文件 名 。 利 用 这 些 占 位 符 ， 人 们 的 常见 需求 都 可 以 被 实现 。 
一 旦 文件 名 被 定义 好 ， 很 自然 地 就 会 考虑 清除 问题 。 有 下 列 设置 可 用 : 
#1og truncate on rotation = off 
#1og rotation age = 1d 
#1og rotation size = 10MB 
默认 情况 下 ， 如 果 日 志文 件 存在 时 间 超 过 一 天 或 者 超过 10MB，PostgreSQL 将 会 持 
续 产 生日 志文 件 。log_truncate_on_rotation 指定 用 户 是 否 想 要 追加 到 一 个 日 志文 件 ， 因 为 
有 时 log_filenames 的 定义 会 让 文件 名 变 成 循环 的 ，log_truncate_on_rotation 参数 规定 是 要 
履 盖 还 是 追加 到 已 经 存在 的 文件 。 对 于 默认 的 日 志文 件 设置 ， 这 种 情况 当然 不 会 发 生 。 
一 种 处 理 自动 轮转 的 方式 是 使 用 类 似 于 postgresql_%a.log 的 命名 外 加 log truncate 
on_rotation = on。%a 意味 着 在 日 志文 件 名 中 使 用 星期 几 相 区 分 ， 其 优点 是 这 样 的 文件 名 
每 七 天 就 会 重复 ， 因 此 日 志文 件 将 在 保留 一 周 后 被 循环 使 用 。 但 如 果 目 标 是 每 周 轮转 ， 
10MB 的 文件 尺寸 可 能 不 够 ， 可 以 考虑 关闭 最 大 文件 尺寸 。 
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2. 配置 syslog 
有 些 人 更 愿意 使 用 syslog 来 收集 日 志文 件 ，PostgreSQL 提供 了 下 列 配置 参数 : 


# These are relevant when logging to syslog: 

#syslog facility = 'LOCALO" 

#syslog ident = 'postgres' 

#syslog sequence numbers = on 

#syslog split messages = on 

syslog 在 sysadmins 中 间 非 常 流行 。 幸 运 的 是 它 很 容易 配置 ， 基 本 上 用 户 只 需要 设置 
一 种 日 志 来 源 和 一 个 标识 符 即 可 。 如 果 log_destination 被 设置 为 syslog， 默 认 设 置 中 就 已 
经 直接 可 以 让 日 志 收集 运转 起 来 了 。 


3 记录 慢 查询 


日 志 也 可 以 被 用 来 跟踪 个 别 慢 的 查询 。 以 前 这 几乎 就 是 找 出 性 能 问题 的 唯一 方法 。 
那 应 该 怎么 做 呢 ? postgresql.conf 有 一 个 名 为 log_ min duration statement 的 变量 。 如 
果 它 被 设置 为 一 个 大 于 零 的 值 ， 每 一 个 超过 该 设置 的 查询 就 会 被 记 入 到 日 志 : 


# log min duration statement = -1 


大 部 分 人 把 慢 查询 日 志 视 为 定位 性 能 问题 的 终极 手段 。 但 是 ， 笔 者 想 多 加 一 句 提 
醒 ， 有 很 多 查询 确实 比较 慢 ， 并 且 它 们 恰好 会 吃 掉 大 量 CPU: 索引 创建 ， 数 据 导 出 ， 数 
据 分 析 等 。 

这 些 长 时 间 运 行 的 查询 完全 是 在 预计 之 中 的 ， 而 且 在 很 多 情况 下 并 非 罪恶 的 根源 。 
其 实 更 多 地 归咎 于 很 多 较 短 的 查询 。 例 如 ，1000 个 查询 X500 毫秒 比 2 个 查询 X5 秒 更 
差 。 在 一 些 情况 下 慢 查 询 日 志 可 能 会 产生 误导 。 

尽管 如 此 ， 也 并 不 意味 着 它 毫 无 意义 一 一 它 只 是 一 种 信息 的 来 源 而 不 是 信息 的 根源 。 

4， 定 义 记 录 什 么 以 及 怎么 记录 

在 看 过 了 一 些 基 本 设置 后 ， 现 在 需要 决定 记录 什么 。 默 认 情况 下 ， 只 有 错误 将 被 记 
录 。 不 过 ， 这 可 能 不 够 。 在 本 节 中 ， 读 者 将 学 到 可 以 记录 什么 以 及 一 个 日 志 行 长 什么 样 。 

默认 情况 下 ，PostgreSQL 不 会 记录 有 关 检 查 点 的 信息 ， 下 面 的 设置 正好 可 以 改变 这 
种 状况 : 

#1l0g checkpoints = off 


同样 的 道理 也 适用 于 连接 。 只 要 一 个 连接 被 建立 或 者 被 正确 地 销毁 ，PostgreSQL 就 
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创建 日 志 项 : 


#1l0g connections = off 
#1l0g disconnections = off 


由 浅 入 深 PostereSQL 


在 大 部 分 情况 下 ， 记 录 连 接 没 有 意义 ， 因 为 昂贵 的 记录 代价 会 明显 拖 慢 系 统 。 分 析 


型 系统 可 能 不 会 受到 什么 影响 ， 但 OLTP 可 


能 会 受到 严重 的 影响 。 


如 果 用 户 想 要 看 看 语句 花 了 多 长 时 间 ， 可 以 考虑 把 下 列 设置 切换 为 on: 


#1l0og duration = off 


让 我 们 进入 最 重要 的 设置 之 一 。 到 目前 为 止 ， 我 们 还 没有 确定 消息 的 布局 ， 并 且 日 


志文 件 包 含 如 下 形式 的 错误 : 


test=# SELECT 1 / 0; 
ERROR: division by zero 


日 志 将 会 记 下 ERROR 以 及 错误 消息 ， 但 没有 时 间 戳 、 用 户 名 等 信息 。 要 改变 这 一 状 


况 ， 可 以 看 看 log line_prefix: 


#1l0g line prefix = "'" 
$a 


大 砷 着 间 大 大 大 非 
op 
H 


op 
Le 


u 


x 


串 唱 唱 串 啡 唱 唱 唱 剧 
Pe] 


op op oP op op op 
< 


op 


special values: 


application name 


user name 


database name 


remote host and port 


remote host 


= process 


ID 


timestamp without milliseconds 


timestamp with milliseconds 


timestamp with milliseconds (as a 


epoch) 

command tag 

SQL state 

session ID 

session line number 

session start timestamp 

virtual transaction ID 
transaction ID (0 if none) 

stop here in non-session processes 
1g! 


log_line_prefix 非常 灵活 并 且 人 允许 用 户 配置 日 志 行 来 匹配 需求 。 通 常 ， 记 录 时 间 惟 是 
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主意 。 和 否则， 基本 上 无 法 知道 不 好 的 事情 是 何 时 发 生 的。 笔者 个 人 还 喜欢 了 解 用 
户 名 、 事 务 ID 和 数据 库 。 不 过 还 是 取决 于 用 户 实际 需要 什么 。 

有 时 速度 慢 是 不 好 的 锁 行 为 造成 的 。 通 常 来 说 锁 相 关 的 问题 很 难 追踪 ，log lock 
waits 有 助 于 检测 到 这 种 问题 。 如 果 打 开 下 面 的 配置 变量 ， 当 一 个 锁 被 持 有 的 时 间 超 过 
deadlock timeout 时 ， 会 有 一 行 被 发 送 到 日 志 : 

#1og_ lock waits = off 


最 后 要 告诉 PostgreSQL 实际 要 记录 什么 。 到 目前 为 止 ， 只 有 错误 、 慢 查询 等 会 被 发 
送 到 日 志 。log_statement 有 3 种 可 能 的 设置 : 

#1og statement = 'none' 

# none, ddl, mod, all 

none 意味 着 只 有 错误 将 被 记录 。ddl 表示 错误 以 及 DDL (CREATE TABLE、ALTER 
TABLE 等 ) 会 被 记录 。mod 包括 数据 更 改 ， 而 all 将 把 每 一 个 语句 都 发 送 到 日 志 。 

人 的 all 可 能 导致 很 多 日 志 信息 ， 这 可 能 会 拖 慢 系 统 。 为 了 让 读者 了 解 影响 有 多 
大 ， 笔 者 编写 了 一 篇 博文 。 
如 果 读 者 想 要 检查 复制 的 细节 ， 考 虑 打开 下 列 设置 : 
#10g replication commands = off 


它 将 把 复制 相关 的 命令 发 送 到 日 志 ( 更 多 信息 请 访问 下 列 网 站 : https://www.postgresql. 
org/docs/9.6/static/protocol-replication.htm!l)。 
日 临时 文件 VO 造成 的 性 能 问题 可 能 会 发 生得 很 频繁 。 要 看 看 哪些 查询 导致 这 类 问 
题 ， 可 以 使 用 下 列 设置 : 
#1l0og temp files = -1 # log temporary files equal or larger 
# than the specified size in kilobytes; 
# -1 disables, 0 logs all temp files 
尽管 pg_stat_statements 3 了 聚合 的 信息 ，log_temp_files 仍 能 找 出 导致 问题 的 特定 
查询 。 通 常 这 个 参数 设置 为 一 个 合理 的 较 低 值 ， 正 确 的 值 取决 于 用 户 的 负载 ， 但 是 4MB 
可 能 是 一 个 好 的 开始 。 
默认 情况 下 ，PostgreSQL 将 以 服务 器 所 在 的 时 区 写 日 志文 件 。 但 是 ， 如 果 用 户 运 行 
的 是 一 个 遍布 全 世界 的 系统 ， 调 整 出 一 个 用 户 可 以 使 用 并 比较 日 志 项 的 时 区 更 加 合理 


log timezone = "Europe/Vienna'" 


记 住 在 SQL 方 ， 用 户 仍 将 看 到 用 户 本 地 时 区 的 时 间 。 不 过 ， 如 果 设 置 这 个 变量 ， 日 
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志 项 会 在 一 个 不 同 的 时 区 中 。 





53 基 结 


本 章 全 都 与 系统 统计 信息 有 关 。 用 户 学 到 了 如 何 从 PostgreSQL 中 抽取 信息 以 及 如 何 
以 有 利 的 方式 使 用 系统 统计 信息 。 本 章 还 详细 讨论 了 最 重要 的 视图 。 第 6 章 将 全 部 与 查 
询 优化 有 关 ， 用 户 将 学 习 如 何 检查 查询 以 及 如 何 优化 它们 。 














第 6 章 优化 查询 获得 良好 性 能 


在 前 几 章 中 ， 读 者 已 经 学 到 了 如 何 阅 读 系 统统 计 信息 以 及 如 何 利用 PostgreSQL 提供 


的 特性 。 有 了 这 些 知 识 的 武装 ， 本 章 将 介绍 同 良好 查询 性 能 有 关 的 内 容 。 读 者 将 进一步 
学 到 与 下 列 主题 有 关 的 内 容 : 

@ 优化 器 内 部 。 

@ 计划 执行 。 

@ 分 区 数据 。 

@ 启用 以 及 禁用 优化 器 设置 。 

@ 与 良好 查询 性 能 有 关 的 参数 。 


在 本 章 结束 时 ， 笔 者 希望 读者 能 写 出 更 好 和 更 快 的 查询 ， 并 且 如 果 查 询 偶然 执行 得 


不 好 时 ， 


读者 应 该 能 够 理解 为 何 出 现 这 样 的 情况 。 


6.1 学 习 优 化 器 的 行为 


在 尝试 思考 查询 性 能 之 前 ， 有 理由 让 读者 先 熟悉 查询 优化 器 的 行为 。 对 后 台 在 进行 
什么 工作 有 更 深入 的 理解 是 非常 有 意义 的 ， 因 为 这 能 帮助 读者 明白 数据 库 将 要 做 的 事情 
以 及 正在 做 的 事情 。 

@ ”通过 例子 理解 优化 











为 了 展示 优化 器 如 何 工作 ， 笔 者 准备 了 一 个 已 经 在 PostgreSQL 培训 中 使 用 了 多 年 的 
例子 。 假 定 有 3 个 表 : 

CREATE TABLE a (aid int, ...); -- 1L 亿 行 

CREATE FABLE VD (Bd ne -- 2 亿 行 

eo Ue ee Bal Ri -- 3 亿 行 


让 我 们 进一步 假设 这 些 表 包含 数 百 万 或 者 可 能 数 亿 行 。 此 外 ， 其 上 还 有 索引 : 


CREATE INDEX idx a ON a (aid); 
CREATE INDEX idx b ON a (biqd); 
CREATE INDEX idx c ON a (cid); 


CREATE VIEW v AS 
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SELECT * 
FROM a, b 
WHERE aid = bid; 
最 后 ， 有 一 个 视图 将 前 两 个 表 连 接 起 来 。 
让 我 们 假定 现在 终端 用 户 想 要 运行 下 面 的 查询 。 优 化 器 将 对 这 个 查询 做 什么 ， 有 哪 
些 选择 ? 
SELECT * 
FROM Wee 


WHERE v-ald = "ce-cid 
AND cid = 4; 


在 着 眼 于 真实 的 执行 处 理 之 前 ， 笔 者 想 要 先 关 注 一 些 规划 器 拥有 的 选项 。 

1.， 评估 连接 选项 

在 这 里 规划 器 有 若干 种 选项 ， 笔 者 想 要 借 此 机 会 展示 如 果 使 用 了 没有 价值 的 方法 ， 
会 出 现 什 么 问题 。 

假定 规划 器 只 是 埋头 苦 干 并 且 计 算 该 视图 的 输出 ， 那 么 连接 1 亿 行 和 2 亿 行 的 最 佳 
方法 是 什么 ? 

在 本 节 中 ， 将 讨论 若干 (并 不 是 全 部 ) 连接 选项 来 展示 PostgreSQL 可 以 做 些 什么 。 

(1) 霸 套 循环 

一 种 连接 两 个 表 的 方式 是 使 用 一 个 嵌 套 循环 。 原 理 非常 简单 ， 这 里 有 一 些 伪 代码 : 

for x in tablel: 

for y in table2: 
if x.field == y.field 
else 
keep doing 

如 果 连 接 的 一 端 非常 小 并 且 只 包含 有 限 的 数据 集合 ， 常 常会 使 用 柑 套 循环 。 在 我 们 
的 例子 中 ， 一 个 嵌 套 循环 会 导致 1 亿 X2 亿 次 迭代 。 这 显然 不 是 一 种 好 的 选项 ， 因 为 运行 
时 间 会 暴涨 。 

嵌 套 循环 的 复杂 度 通 常 是 O(m*)， 因 此 只 有 当 连 接 的 一 端 非 常 小 时 嵌 套 循环 才 有 效 。 
在 笔者 的 例子 中 ， 情 况 当 然 不 是 这 样 ， 因 此 可 以 从 计算 该 视图 的 选项 中 划 掉 嵌 套 循环 。 

(2) 哈 希 连 接 

第 二 种 选项 是 哈 希 连接 。 下 面 的 策略 可 以 解决 我 们 的 一 点 小 问题 : 
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一 哈 希 连接 
一 顺序 扫描 表 1 
一 顺序 扫描 表 2 
连接 的 两 端 都 可 以 被 哈 希 并 且 可 以 通过 比较 哈 希 键 来 得 到 连接 的 结果 。 这 里 的 麻烦 
是 所 有 的 值 都 必须 被 哈 希 并 且 放 在 某 个 地 方 。 
(3) 归并 连接 
最 后 ， 还 有 归并 连接 。 它 的 思想 是 使 用 排序 过 的 列表 来 连接 结果 。 如 果 连 接 的 两 端 
都 是 有 序 的 ， 系 统 可 以 只 是 从 顶部 拿 出 行 ， 看 看 它们 是 否 匹 配 并 且 返 回 它们 。 这 里 的 主 
要 要 求 是 列表 要 是 有 序 的 。 下 面 有 一 个 计划 的 例子 : 
一 归并 连接 
一 排序 表 11 
一 顺序 扫描 表 1 
一 排序 表 2 
一 顺序 扫描 表 2 
要 进行 连接 ， 数 据 必须 以 排 好 序 的 顺序 提供 。 在 很 多 情况 下 ，PostgreSQL 将 会 排序 
数据 。 不 过 ， 还 有 其 他 的 选项 能 为 连接 提供 有 序 的 数据 。 其 中 之 一 是 参考 一 个 索引 ， 如 
下 例 所 示 : 
一 归并 连接 
一 索引 扫描 表 1 
一 排序 表 2 
一 顺序 扫描 表 2 
连接 的 一 端 或 者 两 端 可 以 使 用 来 自 于 计划 较 低层 的 有 序数 据 。 如 果 表 被 直接 访问 ， 
索引 是 一 种 显而易见 的 选择 。 
归并 连接 的 妙 处 在 于 它 能 处 理 大 量 数 据 ， 而 其 缺点 是 数据 必须 被 排序 或 者 在 某 个 时 
刻 从 索引 中 取得 。 
排序 的 复杂 度 是 O(n*log(n))。 因 此 ， 排 序 3 亿 行 数据 来 执行 这 一 查询 也 没有 什么 吸 
引 汶 % 


2， 应 用 转换 


显然 ， 做 那些 显而易见 的 事情 〈 先 连接 视图 ) 根本 没有 意义 。 峰 套 循环 会 让 执行 时 
间 飞 涨 ， 哈 希 连接 必须 哈 希 数 百 万 行 而 归并 连接 "必须 排序 3 亿 行 。 所 有 3 种 选项 显然 都 














日 原文 为 “nested loop”， 应 为 笔 误 。 
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不 适合 这 里 的 情况 ， 比 较 好 的 出 路 是 应 用 逻辑 转换 让 查询 变 快 。 在 本 节 中 ， 读 者 将 学 到 
规划 器 怎样 来 加 速 这 一 查询 。 若 干 个 步骤 会 被 展示 。 

(1) 内 联 视图 

优化 器 做 的 第 一 个 转换 是 内 联 视图 。 就 像 这 样 : 





SELECT * 
FROM (SELECT * 
FROM a, b 


WHERE aid = bid ) ASv, c 
WHERE v.aid = c.cid 
AND cid = 4; 
该 视图 被 内 联 到 查询 中 并 且 转 换 成 一 个 子 查询 。 这 会 为 我 们 带 来 什么 ? 实际 上 ， 什 
么 也 没有 。 它 所 做 的 一 切 只 是 为 进一步 的 优化 打开 了 一 扇 门 ， 优 化 实际 上 才 是 这 个 查询 
的 游戏 规则 改变 者 。 





(2) 扁平 化 子 查询 

下 一 件 事情 是 扁平 化 子 查询 。 去 掉 子 查询 ， 更 多 优化 查询 的 选项 会 出 现 。 
下 面 是 扁平 化 子 查询 之 后 查询 的 样子 : 

SELECT * 


FROM a bie 
WHERE a.aid = c.cid 
AND aid = bid 
AND cid = 4; 
现在 它 是 一 个 普通 的 连接 。 注 意 ， 虽 然 我 们 可 以 自己 完成 这 一 切 ， 但 是 规划 器 会 帮 
我 们 搞定 那些 转换 。 现 在 通 往 关键 优化 的 大 门 已 经 打开 。 


3， 应 用 等 值 约束 


下 面 的 处 理会 创建 等 值 约束 。 其 想法 是 检测 额外 的 约束 、 连 接 选 项 和 过 滤 条 件 。 让 
我 们 深呼吸 并 且 看 看 这 个 查询 : 如 果 aid = cid 且 aid = bid， 我 们 知道 有 bid = cid。 如 果 
cid = 4 且 所 有 其 他 列 也 相等 ， 我 们 就 知道 aid 和 bid 也 必须 是 4， 这 就 把 我 们 导向 了 下 
的 查询 : 
SELECT * 
FROM a» Bae 
WHERE a-.aid = c.cid 
AND aid = bid 
AND cid = 4 
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AND bid = cid 
AND aid = 4 
AND bid = 4 
这 个 优化 的 重要 性 再 怎么 强调 也 不 为 过 。 规 划 器 在 这 里 做 的 是 为 两 个 额外 的 索引 创 
造 了 机 会 ， 这 两 个 索引 在 原始 查询 中 显然 是 用 不 到 的 。 
能 够 在 所 有 3 列 上 使 用 索引 ， 就 没有 必要 再 去 计算 这 个 贵 得 可 怕 的 视图 。PostgreSQL 
有 办 法 只 是 从 索引 检索 到 若干 行 ， 并 且 使 用 任意 合乎 情理 的 连接 选项 。 


4， 穷 举 搜索 


现在 那些 形式 的 转换 已 经 完成 ，PostgreSQL 将 执行 一 次 穷 举 搜索 。 它 将 尝试 所 有 可 
能 的 计划 并 且 将 最 便宜 的 方案 交 给 查询 。PostgreSQL 知道 哪些 索引 是 可 能 的 并 且 使 用 代 
价 模型 来 决定 如 何以 最 好 方法 来 执行 。 

在 穷 举 搜索 期 间 ，PostgreSQL 还 将 尝试 决定 最 好 的 连接 顺序 。 在 原始 查询 中 ， 连 接 
顺序 被 固定 为 A 一 B 和 A 一 C。 但 是 ， 使 用 那些 等 值 约束 我 们 可 以 连接 B 一 C 并 且 之 后 再 
连接 A。 所 有 的 选项 都 在 规划 器 的 考虑 范围 内 。 

在 进行 连接 时 ， 一 般 的 规则 是 在 处 理 中 早早 地 先 去 掉 尽 可 能 多 的 数据 。 如 果 这 些 数 
据 被 去 掉 ， 后 面 它 就 不 会 再 成 为 路 梦 并 且 降 低速 度 。 


5， 全 都 试 一 遍 


现在 所 有 这 些 优化 都 已 经 被 讨论 过 了 ， 是 时 候 看 看 PostgreSQL 能 为 我 们 创建 什么 样 
的 计划 了 : 
test=# explain SELECT * 
FROM Vv, c 
WHERE Vv.aid = c.cid 
AND cid = 4; 
QUERY PLAN 
Nested Loop (cost=1.71..17.78 rows=1 width=12) 
-> Nested Loop (cost=1.14..9.18 rows=1l width=8) 
-> Index Only Scan using idx a on a 
(cost=0.57..4.58 rows=1 width=4) 
Index Cond: (aid = 4) 
-> Index Only Scan using idx b on b 
(cost=0.57..4.59 rows=1 width=4) 
Index Cond: (bid = 4) 
-> Index Only Scan using idx c on c 
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(cost=0.57..80.59 rows=1 width=4) 
Index Cond: (cid = 4) 
(8 rows) 
如 你 所 见 ，PostgreSQL 将 使 用 3 个 索引 。 有 趣 的 是 ，PostgreSQL 决定 使 用 一 个 嵌 套 
循环 来 连接 数据 。 这 是 很 有 意义 的 ， 因 为 几乎 没有 数据 从 索引 扫描 中 产生 。 因 此 ， 使 用 
一 个 循环 来 进行 连接 完全 可 行 并 且 非 常 高 效 的 。 


6. 让 处 理 失 败 


到 目前 为 止 ， 读 者 已 经 看 到 了 PostgreSQL 可 以 为 我 们 做 什么 以 及 优化 器 如 何 帮助 加 
速 查询 。PostgreSQL 相当 聪明 ， 但 它 仍然 需要 聪明 的 用 户 。 在 一 些 情况 中 ， 最 终 用 户 可 
能 做 一 些 思春 的 事情 毁 掉 整个 优化 处 理 。 让 我 们 删除 该 视图 : 

test=# DROP VIEW V7 

DROP VIEW 

现在 重建 视图 。 注 意 在 视图 的 末尾 加 上 了 “OFFSET 0”: 

test=# CREATE VIEW V AS 

SELECT * 

FROM a, b 

WHERE aid = bid 

OFFSET 0; 

CREATE VIEW 

虽然 这 个 视图 逻辑 上 等 效 于 之 前 展示 的 例子 ， 但 优化 器 会 以 不 同 的 方式 对 待 它 。 每 
个 非 0 的 OFFSET 都 将 改变 结果 ， 因 此 该 视图 必须 被 计算 。 整 个 优化 处 理会 被 增加 的 如 
OFFSET 之 流 严重 削弱 。 

PostgreSQL 社区 不 敢 优 化 在 视图 中 放 一 个 “OFFSET 0” 这 种 思春 的 情 
6 况 ， 人 们 根本 不 会 那样 做 。 笔 者 在 这 里 只 是 把 它 用 作 一 个 例子 来 展示 一 些 操作 
可 能 会 前 弱 性 能 ， 并 且 开 发 者 应 该 意识 到 底层 的 优化 处 理 。 





这 里 是 新 的 计划 : 


test=# EXPLAIN SELECT * 
FROM Vv, c 
WHERE v.aid = c.cid 
AND cid = 4; 
QUERY PLAN 
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Nested Loop (cost=120.71..7949879.40 rows=1 width=12) 
-> Subquery Scan on v 
(cost=120.13. .7949874.80 rows=1 width=8) 
Filter: (v.aid = 4) 
-> Merge Join (cost=120.13..6699874.80 
rows=100000000 width=8) 

Merge Cond: (a.aid = b.bid) 

-> Index Only Scan using idx a on a 
(cost=0.57..2596776.57 rows=100000000 
width=4) 

-> Index Only Scan using idx b on b 
(cost=0.57..5193532.33 rows=199999984 
width=4) 

-> Index Only Scan using idx c on c 
(cost=0.57..4.59 rows=1 width=4) 
Index Cond: (cid = 4) 
(9 rows) 


只 需要 看 一 下 规划 器 预测 的 代价 ， 代 价 像 坐 火 箭 一 样 从 一 个 两 位 数 磷 升 到 了 一 
人 震惊 的 数字 。 很 明显 ， 这 个 查询 将 会 为 用 户 提供 不 好 的 性 能 。 
有 更 多 的 方式 可 以 削弱 性 能 ， 因 此 牢记 优化 过 程 是 有 意义 的 。 


7， 常 量 折 又 


不 过 ， 在 PostgreSQL 中 有 更 多 的 优化 在 后 台 进 行 并 且 为 总 体 的 好 性 能 做 出 贡献 。 


些 特性 之 一 叫 作 常量 折 又 。 其 思想 是 把 表达 式 转化 成 常量 ， 如 下 例 所 示 : 


test=# explain SELECT * FROM a WHERE aid = 3 + 1; 
QUERY PLAN 
Index Only Scan using idx a on a 
(cost=0.57..4.58 rows=1 width=4) 
Index Cond: (aid = 4) 
(2 rows) 


如 你 所 见 ，PostgreSQL 将 尝试 查找 4。 由 于 aid 上 有 索引 ，PostgreSQL 将 会 进行 一 


个 令 


这 


索引 扫描 。 注 意 我 们 的 表 只 有 一 列 ， 因 此 PostgreSQL 甚至 ee pa 


有 数据 。 
如 果 该 表达 式 在 左手 边 会 发 生 什么 ? 
test=# explain SELECT * FROM a WHERE aid - 1 = 3; 
QUERY PLAN 
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Seq Scan on a (cost=0.00..1942478.48 rows=500000 width=4) 
Filter: ((aid - 1) = 3) 
(2 rows) 


在 这 种 情况 下 ， 索 引 查找 会 失败 并 且 PostgreSQL 只 能 求助 于 一 个 顺序 扫描 。 
8。， 理解 函数 内 联 


正如 本 节 中 已 经 提 到 的 ， 有 很 多 优化 可 以 帮助 加 速 查询 ， 其 中 之 一 被 称 作 函 数 内 
联 。PostgreSQL 能 够 内 联 不 可 变 SQL 函数 ， 主 要 的 思想 是 减少 必须 要 做 的 函数 的 调用 次 
数 以 提高 速度 。 

这 里 是 一 个 函数 的 例子 : 

test=# CREATE OR REPLACE FUNCTION ldl(int) 

RETURNS numeric AS 


$$ 
SELECT log(2, $1); 








$5 
LANGUAGE ‘sql' IMMUTABLE; 
CREATE FUNCTION 


该 函数 将 计算 输入 值 的 对 数 二 元 (logarithmus dualis) : 


test=# SELECT 1d(1024); 
ld 


10.0000000000000000 
(1 row) 
为 了 展示 工作 原理 ， 笔 者 将 用 较 少 的 内 容重 建 该 表 以 便 加 速 索引 创建 : 
test=# TRUNCATE a; 
TRUNCATE TABLE 
然后 可 以 再 次 加 入 数据 并 且 创建 索引 : 


test=# INSERT INTO a SELECT * FROM generate series (1，10000) 
INSERT 0 10000 

test=# CREATE INDEX idx ld ON a (ld(aiqd)); 

CREATE INDEX 


不 出 所 料 ， 在 该 函数 上 创建 的 索引 就 像 任何 其 他 索引 一 样 派 上 了 用 场 。 但 是 ， 仔 细 
看 看 索引 条 件 : 
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QUERY PLAN 


Index Scan using idx ld on a (cost=0.29..8.30 rows=1 width=4) 


Index Cond: (log('2'::numeric, (aid)::numeric) = "10'::numeric) 
(2 rows) 
这 里 的 重要 观察 是 ， 索 引 条 件 实际 查找 的 是 log 函数 而 不 是 ld 函数 。 优 化 器 完全 去 
掉 了 那 一 次 函数 调用 。 


逻辑 上 来 讲 ， 这 为 下 面 的 查询 提供 了 机 会 : 


test=# EXPLAIN SELECT * FROM a WHERE log(2, aid) = 10; 
QUERY PLAN 


Index Scan using idx ld on a (cost=0.29..8.30 rows=1 width=4) 
Index Cond: (log('2'::numeric, (aid)::numeric) = '10'::numeric) 
(2 rows) 


9， 连 接 剪 枝 


PostgreSQL 提供 一 种 名 为 连接 剪 枝 的 优化 ， 其 思想 是 移 除 查 询 不 需要 的 连接 。 这 在 
查询 由 某 种 中 间 件 或 者 ORM 生成 的 场景 中 派 得 上 用 场 。 如 果 一 个 连接 可 以 被 移 除 ， 这 自 
然 会 显著 地 提高 速度 并 且 导 致 较 少 的 开销 。 

现在 的 问题 是 ， 连接 剪 枝 如何 工 作 ? 这 里 有 一 个 例子 : 

CREATE TABLE x (id int, PRIMARY KEY (id)); 

CREATE TABLE y (id int, PRIMARY KEY (id)); 

首先 ， 两 个 表 被 创建 ， 确 保 连 接 条 件 的 两 端 实际 上 都 是 唯一 的 。 那 些 约束 一 会 儿 会 
非常 重要 。 
现在 可 以 写 一 个 简单 的 查询 : 
test=# EXPLAIN SELECT * 

FROM x LEFT JOIN y 


ON (x.id = y.id) 
WHERE x.id = 3; 





QUERY PLAN 
Nested Loop Left Join (cost=0.31..16.36 rows=1 width=8) 
Join Filter: (x.id = y.id) 
-> Index Only Scan using x pkey on x 
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(Ecost=0.1528517 rows=1 width=4) 
Index Cond: (id = 3) 
-> Index Only Scan using y pkey on y 
(cost=0.15..8.17 rows=1 width=4) 
Index Cond: (id = 3) 
(6 rows) 


如 你 所 见 ，PostgreSQL 直接 连接 这 些 表 ， 目 前 为 止 没有 意外 出 现 。 不 过 ， 下 面 的 查 
询 有 一 点 修改 。 它 只 选择 那些 位 于 连接 左手 边 的 列 ， 而 不 是 所 有 列 
test=# explain SELECT x.* 
FROM x LEFT JOIN y 
ON (x.id = y.id) 
WHERE x.id = 3; 
QUERY PLAN 


ee 
(cost=0.15..8.17 rows=1 width=4) 
Index Cond: (id = 3) 

(2 rows) 

PostgreSQL 将 进行 一 个 直接 的 内 侧 扫 描 ， 并 且 完 全 跳 过 连接 。 能 够 这 样 做 旦 逻辑 上 

正确 的 原因 有 两 点 : 
@ ”没有 选择 从 连接 的 右边 出 列 ， 因 此 查看 那些 列 不 会 为 我 们 带 来 任何 好 处 。 
@ 右 侧 是 唯一 的 ， 这 意味 着 连接 不 会 由 于 右 侧 的 重复 而 增加 行 数 。 





如 果 连 接 能 被 自动 地 前 枝 ， 查 询 的 速度 可 能 会 提高 一 个 量 级 。 这 里 的 妙 处 在 于 ， 只 


是 通过 移 除 应 用 不 需要 的 列 就 能 实现 提速 。 
10. 加速 集 合 操作 


集合 操作 允许 多 个 查询 的 结果 被 组 合成 一 个 结果 集 ， 集 合 操作 符 包括 UNION、 
INTERSECT 和 EXCEPT。PostgreSQL 实现 了 所 有 这 几 种 操作 符 ， 并 且 提 供 了 很 多 重要 的 
优化 来 为 它们 加 速 。 

规划 器 能 够 把 限制 下 推 到 集合 操作 ， 这 就 为 精巧 的 索引 和 一 般 的 加 速 普遍 提供 了 机 
会 。 让 我 们 看 看 下 面 的 查询 ， 它 会 展示 其 中 的 道理 : 

test=# EXPLAIN SELECT * 

FROM ( 

SELECT aid AS xid 


FROM a 
UNION ALL 
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SELECT bid 
FROM b 
) ASy 
WHERE xid = 3; 
QUERY PLAN 
Append (cost=0.29..12.89 rows=2 width=4) 
-> Index Only Scan using idx a on a 
(cost=0.29..8.30 rows=1 width=4) 
Index Cond: (aid = 3) 
-> Index Only Scan using idx b on b 
(cost=0.57..4.59 rows=1 width=4) 
Index Cond: (bid = 3) 
(5 rows) 


从 中 可 以 看 到 ， 两 个 关系 被 相互 加 在 一 起 。 问 题 是 唯一 的 限制 在 子 查询 之 外 。 不 
过 ，PostgreSQL 发 现 这 个 过 滤 条 件 能 在 计划 中 进一步 被 下 推 。 因此 ，xid = 3 被 附 在 aid 和 
bid 上 ， 为 在 两 个 表 上 使 用 索引 打开 了 选项 。 通 过 避免 两 个 表 上 的 顺序 扫描 ， 该 查询 将 会 
运行 得 快 很 多 。 

注意 ，UNION 子 句 和 UNION ALL 子 句 有 一 点 区 别 。UNION ALL 子 句 只 是 讶 目地 
追加 数据 并 且 传 递 出 两 个 表 的 结果 。 而 UNION 子 句 不 同 ， 它 将 过 滤 掉 重复 。 下 面 的 计划 
展示 了 其 工作 原理 : 

test=# EXPLAIN SELECT * 

FROM ( 

SELECT aid AS xid 

FROM a 

UNION 

SELECT bid 

FROM b 

) Rs y 

WHERE xid = 3; 

QUERY PLAN 
Unique (cost=12.92..12.93 rows=2 width=4) 
-> Sort (cost=12.92..12.93 rows=2 width=4) 
Sort Key: a.aid 
-> Append (cost=0.29..12.91 rows=2 width=4) 
-> Index Only Scan using idx a on a 

(cost=0.29..8.30 rows=1 width=4) 
Index Cond: (aid = 3) 
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-> Index Only Scan using idx b on b 
(cost=0.57..4.59 rows=1 width=4) 
Index Cond: (bid = 3) 
(8 rows) 
PostgreSQL 不 得 不 在 Append 节点 的 上 面 增加 一 个 Sort 节点 来 确保 后 面 可 以 过 滤 掉 
重复 。 


很 多 没有 完全 认识 到 UNION 子 句 和 UNION ALL 子 句 区 别 的 人 会 抱怨 性 
€9 能 不 好 ， 因 为 他 们 没有 意识 到 PostgreSQL 必须 过 滤 掉 重复 ， 这 种 操作 在 大 型 数 
据 集 的 情况 下 是 特别 痛苦 的 


6.2 ”理解 执行 计划 


在 钻研 了 一 些 PostgreSQL 实现 的 重要 优化 之 后 ， 笔 者 想 把 读者 的 注意 力 更 多 地 转向 
执行 计划 。 读 者 已 经 在 本 书 中 见 过 一 些 计 划 。 不 过 ， 为 了 完整 地 利用 计划 ， 形 成 一 种 阅 
读 这 种 信息 的 系统 方法 很 重要 ， 而 这 正好 就 是 本 节 要 讨论 的 范畴 。 


6.2.1 系统 地 处 理 计 划 


第 一 件 要 了 解 的 是 ，EXPLAIN 子 句 可 以 做 很 多 工作 ， 笔 者 强烈 建议 用 户 充分 利用 这 
些 特性 。 
正如 很 多 读者 已 经 知道 的 ， 一 个 EXPLAIN ANALYZE 子 句 将 执行 查询 ， 并 且 返 回 包 
括 实际 运行 时 信息 的 计划 。 这 里 有 一 个 例子 : 
test=# EXPLAIN ANALYZE SELECT * 
FROM (SELECT * 
FROM b 
LIMIT 1000000 


) ASb 
ORDER BY cos (bid); 








QUERY PLAN 
Sort (cost=146173.12..148673.12 rows=1000000) 
(actual time=837.049..1031.587 rows=1000000) 
Sort Key: (cos((b.bid)::double precision)) 
Sort Method: external merge Disk: 25408kB 
-> Subquery Scan on b 
(cost=0.00..29424.78 rows=1000000 width=12) 
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(actual time=0.011..352.717 rows=1000000) 
-> Limit (cost=0.00..14424.78 rows=1000000) 
(actual time=0.008..169.784 rows=1000000) 
-> Seq Scan on bb 1 (cost=0.00..2884955.84 
rows=199999984 width=4) 
(actual time=0.008..85.710 rows=1000000) 
Planning time: 0.064 ms 
Execution time: 1159.919 ms 
(8 rows) 


这 个 计划 看 起 来 有 点 吓人 ， 但 也 不 必 丽 慌 ， 我 们 将 逐步 地 理解 它 。 在 阅读 一 个 计划 
时 ， 要 确保 从 内 向 外 进行 阅读 。 在 笔者 的 例子 中 ， 执 行 从 b 上 的 一 个 顺序 扫描 开始 。 这 
里 实际 有 两 块 信息 : 代价 块 和 实际 时 间 块 。 虽 然 代价 块 包 含 的 是 估计 ， 但 实际 时 间 块 中 
却 是 真 赁 实 据 ， 它 显示 实际 的 执行 时 间 。 在 这 个 例子 中 ， 该 顺序 扫描 花费 了 85.7 毫秒 。 

然后 数据 被 传递 给 Limit 节点 ， 确 保 不 会 有 太 多 数据 。 注 意 执行 的 每 个 阶段 还 向 我 们 
展示 涉及 的 行 数 。 如 你 所 见 ，PostgreSQL 只 从 表 的 最 初 取得 1 百 万 行 ，Limit 节点 会 确保 
这 一 点 。 不 过 ， 这 是 要 付出 代价 的 ， 在 这 一 阶段 ， 运 行 时 间 已 经 跳 到 了 169 毫秒 。 

最 后 ， 数 据 花 了 很 多 时 间 被 排序 。 在 查看 该 计划 时 最 重要 的 事情 是 找到 时 间 到 底 损 
失 在 了 什么 地 方 。 最 好 的 办 法 是 看 看 实际 时 间 块 ， 并 且 尝 试 找 出 时 间 暴 涨 的 地 方 。 在 这 
个 例子 中 ， 顺 序 扫描 花 了 一 些 时 间 ， 但 它 无 法 被 明显 地 提速 。 相 反 可 以 看 到 在 排序 开始 
时 ， 时 间 就 开始 飞涨 。 
当然 ， 排 序 可 以 被 加 速 ， 本 章 后 面 的 部 分 会 对 此 介绍 更 多 。 

@ 让 EXPLAIN 更 详细 
在 PostgreSQL 中 ，EXPLAIN 子 名 的 输出 可 以 被 充实 一 点 来 为 用 户 提供 更 多 信息 。 要 
从 计划 中 尽 可 能 多 地 榨取 信息 ， 考 虑 把 下 列 选项 打开 : 
test=# EXPLAIN ( 
analyze true, 











Verbose true, 

costs true, 

timing true, 

buffers true) 

SELECT * FROM a ORDER BY random(); 
QUERY PLAN 
Sort (cost=834.39..859.39 rows=10000 width=12) 

(actual time=6.089..7.199 rows=10000 loops=1) 
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Output: aid, (random()) 
Sort Key: (random()) 
Sort Method: quicksort Memory: 853kB 
Buffers: shared hit=45 
-> Seq Scan on public.a 
(cost=0.00..170.00 rows=10000 width=12) 
(actual time=0.012..2.625 rows=10000 loops=1) 
Output: aid, random() 
Buffers: shared hit=45 
Planning time: 0.054 ms 
Execution time: 7.992 ms 
(10 rows) 


analyze true 像 前 面 展 示 的 那样 实际 地 执行 查询 。verbose true 增加 更 多 的 信息 到 该 计 
划 〔 例 如 列 信 息 等 ) 。costs true 显示 有 关 代 价 的 信息 。timing true 同样 重要 ， 因 为 它 将 为 
我 们 提供 好 的 运行 时 数据 ， 这 样 我 们 可 以 看 到 时 间 损 失 在 计划 中 的 哪个 部 分 。 最 后 ， 还 
有 buffers true， 它 可 能 会 非常 有 启发 作用 。 在 笔者 的 例子 中 ， 它 显示 我 们 用 到 了 45 个 组 
冲 区 来 执行 该 查询 。 


6.2.2 发现 问题 


根据 第 5 章 中 展示 的 所 有 信息 ， 已 经 可 以 发 现 若干 潜在 的 性 能 问题 ， 它 们 在 实际 生 
活 中 非常 重要 。 


1， 发 现 运行 时 间 中 的 变化 


在 查看 一 个 计划 时 ， 用 户 总 是 会 问 自己 两 个 问题 : 

@ EXPLAIN ANALYZE 子 句 展示 的 运行 时 间 对 于 给 定 查询 合乎 情理 吗 ? 

@ ”如 果 该 查询 很 乙 ， 运 行 时 间 是 在 哪里 暴涨 的 ? 

在 笔者 的 例子 中 ， 顺 序 扫描 被 估价 为 2.625 毫秒 。 排 序 在 7.199 毫秒 后 完成 ， 因 此 排 
序 用 了 大 约 4.5 毫秒 来 完成 ， 所 以 它 应 该 对 该 查询 所 需 的 运行 时 间 负 大 部 分 的 责任 。 
在 查询 的 执行 时 间 中 寻找 暴涨 点 将 会 揭示 到 底 在 发 生 什么 。 根 据 哪 种 操作 烧 掉 太 多 
时 间 ， 用 户 必须 做 出 相应 的 应 对 。 这 里 不 可 能 给 出 一 般 性 的 建议 ， 只 是 因为 有 太 多 事情 
可 能 会 导致 那些 问题 。 


2. 检查 估计 值 
但 是 ， 有 一 些 事情 总 是 要 做 的 : 确保 估计 值 和 实际 的 数字 相当 接近 。 在 某 些 情况 
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下 ， 优 化 器 将 做 出 不 好 的 决定 ， 因 为 估计 值 由 于 某 种 原因 大 错 特 错 。 估 计 值 错误 可 能 
于 系统 统计 信息 过 时 导致 ， 因 此 运行 一 个 ANALYZE 子 句 绝对 是 解决 这 类 问题 最 好 的 出 
发 点 。 但 是 ， 优 化 器 的 统计 信息 大 部 分 由 autovacuum 守护 进程 照管 ， 因 此 绝对 值得 考虑 
其 他 导致 不 良 估计 值 的 选项 。 看 看 下 面 的 例子 : 

test=# CREATE TABLE t estimate AS 

SELECT * FROM generate series(1, 10000) RS id; 
SELECT 10000 
在 载 入 10000 行 后 ， 优 化 器 统计 信息 被 创建 : 


test=# ANALYZE t estimate; 
ANALYZE 








让 我 们 现在 来 看 看 估计 值 : 
test=# EXPLAIN ANALYZE SELECT * 
FROM t estimate 
WHERE cos(id) < 4; 
QUERY PLAN 
Seq Scan on t estimate (cost=0.00..220.00 rows=3333 width=4) 
(actual time=0.010..4.006 rows=10000 loops=1) 
Filter: (cos((id)::double precision) < '4'::double precision) 
Planning time: 0.064 ms 
Execution time: 4.701 ms 
(4 rows) 


在 很 多 情况 下 ，PostgreSQL 可 能 无 法 正确 地 处 理 WHERE 子 句 ， 因 为 它 只 有 列 上 的 
统计 信息 而 没有 表达 式 的 统计 信息 。 在 这 里 看 到 从 WHERE 子 句 返回 的 数据 被 严重 地 低 
估 了 。 
当然 ， 还 可 能 发 生 数 据 量 被 高 估 的 情况 : 


test=# EXPLAIN ANALYZE SELECT * 

FROM t estimate 

WHERE cos(id) > 4; 

QUERY PLAN 

Seq Scan on t estimate (cost=0.00..220.00 rows=3333 width=4) 
(actual time=3.802..3.802 rows=0 loops=1) 

Filter: (cos((id)::double precision) > '4'::double precision) 
Rows Removed by Filter: 10000 
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Planning time: 0.037 ms 
Execution time: 3.813 ms 


(5 rows) 


如 果 这 类 事情 发 生 在 计划 的 深 处 ， 该 过 程 将 很 可 能 创建 一 个 不 好 的 计划 。 因 此 ， 确 
保 估 计 值 在 某 个 范围 内 的 意义 非凡 。 

幸运 的 是 ， 有 一 种 方法 可 以 应 付 这 种 问题 : 

test=# CREATE INDEX idx cosine ON 七 estimate (cos(id)); 

CREATE INDEX 

创建 一 个 索引 将 让 PostgreSQL 跟踪 该 表达 式 的 统计 信息 : 


test=# ANALYZE; 
ANALYZE 


除 这 个 计划 将 确保 明显 更 好 的 性 能 之 外 ， 它 还 将 修正 统计 信息 一 一 即便 不 使 用 索引 : 
test=# EXPLAIN ANALYZE SELECT * 

FROM t estimate 

WHERE cos(id) > 4; 

QUERY PLAN 





Index Scan using idx cosine on t estimate 
(cost=0.29..8.30 rows=1 width=4) 

(actual time=0.002..0.002 rows=0 loops=1) 
Index Cond: (cos((id)::double precision) 
> '4'::double precision) 

Planning time: 0.095 ms 

Execution time: 0.011 ms 

(4 rows) 


不 过 ， 除 呈现 在 眼前 的 错误 估计 之 外 ， 还 有 更 多 可 能 。 一 种 常 被 低估 的 问题 叫 作 跨 
列 关 联 。 考 虑 这 个 涉及 两 个 列 的 简单 例子 : 

@ ”20% 的 人 喜欢 滑雪 。 

@ 20% 的 人 来 自 非洲 。 

如 果 我 们 想 要 对 来 自 非洲 的 滑雪 者 计数 ， 数 学 运算 会 告诉 我 们 结果 是 总 群体 的 0.2X 
0.2 = 4%。 不 过 ， 在 非洲 没有 雪 而 且 收 入 较 低 ， 因 此 实际 的 结果 肯定 将 会 更 低 。 对 非洲 的 
观察 和 对 滑雪 的 观察 不 是 统计 独立 的 。 在 很 多 情况 下 ， 事 实 是 PostgreSQL 保留 的 列 统 计 
信息 不 会 跨越 超过 一 列 ， 这 就 会 导致 不 好 的 结果 。 当 然 ， 规 划 器 会 做 很 多 努力 来 阻止 这 
类 事情 发 生 。 但 是 ， 它 仍然 可 能 是 一 个 问题 。 
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从 PostgreSQL 10.0 开始 ， 很 可 能 在 PostgreSQL 中 看 到 多 元 统计 信息 ， 这 将 一 劳 永 逸 
地 终结 跨 列 关联 问题 。 


3 检查 缓冲 区 使 用 


不 过 ， 计 划 本 身 并 非 导 致 问题 的 唯一 因素 。 很 多 情况 下 ， 和 危险 隐藏 在 某 个 其 他 层次 
上 。 内 存 和 缓冲 可 能 会 导致 意外 的 行为 ， 对 于 那些 没有 被 训练 查看 本 节 描 述 的 问题 的 最 
终 用 户 来 说 ， 这 些 行 为 通常 很 难 理解 。 

















这 里 有 一 个 例子 : 
test=# CREATE TABLE t random AS 
SELECT * 


FROM generate series(1, 10000000) RS id 
ORDER BY random(); 

SELECT 10000000 

test=# ANALYZE t random ; 

ANALYZE 


笔者 已 经 产生 了 一 个 包含 10000000 行 的 简单 表 并 且 创建 好 了 优化 器 统计 信息 。 下 一 
步 ， 执 行 一 个 只 检索 少量 行 的 简单 查询 : 


test=# EXPLAIN (analyze true, buffers true, costs true, timing true) 
SELECT * 
FROM t random 
WHERE id < 1000; 
QUERY PLAN 
Seq Scan on t random (cost=0.00..169248.60 rows=1000 width=4) 
(actual time=1.068..685.410 rows=999 loops=1) 
Filters Mad < T1000) 
Rows Removed by Filter: 9999001 
Buffers: shared hit=2112 read=42136 
Planning time: 0.035 ms 
Execution time: 685.551 ms 
(6 rows) 


在 观察 数据 之 前 ， 该 查询 确保 已 经 执行 了 两 次 。 当 然 ， 也 可 以 在 这 里 使 用 一 个 索 
引 。 但 是 ， 笔 者 想 要 点 出 的 是 另外 一 件 事情 。 在 笔者 的 查询 中 ，PostgreSQL 在 缓存 中 找 
了 2112 个 缓冲 区 ， 并 且 从 操作 系统 拿 到 42136? 个 缓冲 区 。 现 在 可 能 发 生 两 件 事 : 如 果 足 








9 此 处 上 文 的 执行 计划 中 read=42136， 原 文中 这 里 的 421136 应 该 是 笔 误 。 
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够 幸运 ， 操 作 系统 会 达到 若干 次 缓存 命中 并 且 查询 会 很 快 ， 如 果 文 件 系统 缓存 不 那么 幸 
运 ， 那 些 块 就 必须 从 磁盘 取得 。 这 可 能 是 显而易见 的 ， 然 而 ， 它 可 能 会 导致 执行 时 间 的 
剧烈 变化 。 一 个 完全 在 缓存 中 运行 的 查询 可 能 比 一 个 需要 缓慢 从 磁盘 收集 随机 块 的 查询 
快 100 倍 。 

让 我 们 尝试 使 用 一 个 简单 的 例子 勾勒 这 个 问题 。 假 设 我 们 有 一 个 电话 系统 ， 它 存储 
了 10000000000 行 〈 在 大 型 电话 运营 商 中 并 不 罕见 ) 。 数 据 以 一 个 非常 快 的 速率 流入 并 
且 用 户 想 要 查询 这 些 数据 。 如 果 有 10000000000 行 ， 数 据 将 只 能 部 分 放 入 内 存 ， 因 此 很 
多 东西 都 将 自然 地 来 自 于 磁盘 。 

现在 我 们 可 以 运行 一 个 简单 的 查询 : 


SELECT * FROM data WHERE phone number = "+12345678 "7 


即便 用 户 正在 打 电 话 ， 他 /她 的 数据 也 将 散布 在 各 处 。 如 果 用 户 结束 一 次 通话 然后 开 
始 下 一 次 通话 ， 数 以 千 计 的 人 也 会 做 同样 的 事情 ， 因 此 用 户 的 两 次 通话 结束 于 完全 相同 
的 8000 字 节 块 的 几率 自然 近乎 于 零 。 只 是 想象 一 下 同时 有 100000 个 通话 进行 的 时 段 。 
在 磁盘 上 ， 数 据 将 被 随机 分 布 。 在 用 户 的 电话 号 码 经 常 出 现 的 情况 下 ， 这 意味 着 对 每 一 
行 至 少 有 一 块 已 经 被 从 磁盘 上 取出 (假定 缓冲 命中 率 很 低 ) 。 假 定 有 5000 行将 被 返回 。 
假设 用 户 必须 去 访问 磁盘 5000 次 ， 这 将 导致 5000X5 毫秒 = 25 秒 的 执行 时 间 。 注 意 这 一 
查询 的 执行 时 间 可 能 会 在 数 毫秒 到 30 秒 之 间 变 化 ， 取 决 于 有 多 少数 据 被 操作 系统 或 者 
PostgreSQL 所 缓存 。 

记 住 每 一 次 服务 器 重启 将 清空 PostgreSQL 和 文件 系统 缓存 ， 这 将 导致 节点 失效 后 的 
大 麻烦 。 


4 修正 高 缓冲 区 使 用 
现在 的 问题 是 ， 怎 样 才能 改进 这 种 状况 ? 一 种 方法 是 运行 CLUSTER 子 句 : 


test=# \h CLUSTER 

















Command: CLUSTER 
Description: cluster a table according to an index 
Syntax: 


CLUSTER [VERBOSE] table name [ USING index name ] 

CLUSTER [VERBOSE] 

CLUSTER 子 句 将 按照 一 个 (B 树 ) 索引 的 相同 顺序 重 写 表 。 如 果 正 在 运行 一 种 分 析 
型 负载 ， 这 种 做 法 会 有 意义 。 不 过 ， 在 一 个 OLTP 系统 中 ，CLUSTER 子 句 可 能 就 行 不 
通 ， 因 为 在 该 表 被 重 写 期 间 要 求 一 个 表 锁 。 
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6.3 理解 并 且 固 定 连接 


连接 是 一 种 重要 的 操作 ， 每 个 人 都 经 常会 需要 用 到 它们 。 因 此 ， 连 接 也 与 维护 或 达 
到 良好 性 能 相关 。 为 了 确保 能 写 出 好 的 连接 ， 笔 者 决定 在 本 书 中 用 一 节 来 介绍 连接 。 


6.3.1 正确 使 用 连接 


在 深入 优化 连接 之 前 ， 务 必要 看 一 些 与 连接 同时 出 现 的 最 常见 的 问题 ， 它 们 应 该 会 
对 用 户 敲 起 警钟 。 

这 里 有 一 个 例子 : 

test=# CREATE TABLE a (aid int) 7 

CREATE TABLE 

test=# CREATE TABLE b (bid int); 

CREATE TABLE 

test=# INSERT INTO a VALUES (1), (2), (3); 

INSERT 0 3 

test=# INSERT INTO b VALUES (2), (3), (4); 

INSERT 0 3 


在 下 一 个 例子 中 ， 读 者 将 看 到 一 个 简单 的 外 连接 : 


test=# SELECT * FROM a LEFT JOIN b ON (aid = bid); 





aid | bid 
二 三 = 二 二 三 
1 1 

2 1 2 
3 1 3 
(3 rows) 


可 以 看 到 PostgreSQL 将 从 左手 边 拿 出 所 有 行 ， 并 且 只 列 出 符合 条 件 的 行 。 
接 下 来 的 例子 可 能 会 让 很 多 人 感到 惊奇 : 


test=# SELECT * FROM a LEFT JOIN b ON (aid = bid AND bid = 2); 


aid | bid 
ee tp 
1 

之 1 2 
3 1 
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是 的 ， 行 数 没有 减少 一 一 它 仍然 保持 一 个 常数 。 大 部 分 人 会 设想 在 连接 中 将 只 有 一 
行 ， 但 并 不 是 这 样 并 且 将 导致 某 些 隐藏 的 问题 。 

考虑 下 列 查询 : 

test=# SELECT avg(aid), avg (bid) 


FROM a LEFT JOIN b 
ON (aid = bid AND bid = 2); 


2.0000000000000000 | 2.0000000000000000 

(1 row) 

大 部 分 人 会 设想 这 个 均值 是 基于 一 个 单个 行 计算 的 。 但 是 ， 正 如 前 面 一 点 所 说 的 ， 事 
实 并 非 如 此 ， 因 而 类 似 这 样 的 查询 常常 被 认为 是 一 种 性 能 问题 。 由 于 某 种 原因 ， 
PostgreSQL 没有 对 连接 左边 的 表 做 索引 。 当 然 ， 我 们 这 里 看 到 的 并 不 是 一 种 性 能 问题 
它 无 疑 是 一 种 语义 问题 。 人 们 书写 的 外 连接 与 想 让 PostgreSQL 做 的 事情 不 符 的 情况 经 常 
发 生 。 因 此 ， 笔 者 的 个 人 建议 是 在 解决 客户 报告 的 性 能 问题 之 前 ， 总 是 先 质疑 一 下 外 连 
接 的 语义 正确 性 。 

这 种 工作 对 于 确保 查询 正确 非常 重要 ， 笔 者 觉得 再 怎么 强调 都 不 为 过 。 


6.3.2 ”处 理 外 连接 


在 从 业务 的 角度 验证 了 查询 确实 正确 之 后 ， 就 可 以 检查 优化 器 能 做 些 什么 来 加 速 外 
连接 。 最 重要 的 事情 是 ，PostgreSQL 在 很 多 情况 下 通过 重 排 序 内 连接 来 显著 地 提速 。 但 
是 ， 在 外 连接 的 情况 下 ， 并 不 是 总 能 这 样 。 实 际 上 只 允许 少数 重 排序 操作 的 Pac: 

(A leftjoin B on (Pab)) innerjoin C on (Pac)=(A innerjoin C on (Pac)) leftjoin B on (Pab) 

Pac 是 一 个 引用 A 和 C 的 谓词 ， 诸 如 此 类 (在 这 个 例子 中 ， 显 然 Pac 不 能 引用 B， 否 
则 转换 就 是 没有 意义 的 ) : 

(A leftjoin B on (Pab)) leftjoin C on (Pac) = (A leftjoin C on (Pac)) leftjoin B on (Pab) 

(A leftjoin B on (Pab)) leftjoin C on (Pbc) = (A leftjoin (B leftjoin C on (Pbc)) on (Pab) 

只 有 谓词 Pbc 对 所 有 为 空 的 B 行 都 必然 失败 〈 即 Pbc 对 B 的 至 少 一 列 是 严格 的 )。 
如 果 Pbc 不 严格 ， 第 一 种 形式 可 能 会 产生 一 些 有 非 空 C 列 的 行 ， 而 第 二 种 形式 会 让 这 些 

虽然 一 些 连接 可 以 被 重 排序 ， 但 有 一 种 典型 的 查询 无 法 从 连接 重 排序 获 益 : 

SELECT 


FROM a LEFT JOIN b ON (aid = bid) 
LEFT JOIN c ON (bid = cid) 
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LEFT JOIN d ON (cid = did) 


其 解决 之 道 是 检查 是 否 所 有 的 外 连接 真 的 都 是 必需 的 。 很 多 情况 下 ， 人 们 会 在 不 需 
要 外 连接 的 地 方 写 上 外 连接 。 通 常 ， 商 业 案例 甚至 没有 使 用 外 连接 的 必要 性 。 


6.3.3 理解 join_collapse_limit 变量 


在 规划 处 理 期 间 ，PostgreSQL 会 尝试 检查 所 有 可 能 的 连接 顺序 。 很 多 情况 下 ， 这 个 过 
程 可 能 会 相当 昂贵 ， 因 为 可 能 会 有 多 种 排列 ， 它 们 自然 拖 慢 规划 处 理 。join_collapse_limit 
变量 给 了 开发 者 一 种 工具 来 实际 地 解决 这 些 问题 ， 并 且 以 更 直接 的 方式 定义 了 一 个 查询 
应 该 如 何 被 处 理 。 

为 了 展示 有 关 这 一 设置 的 一 切 ， 笔 者 已 经 编 好 了 一 个 小 例子 : 


SELECT 本 
FROM tabl, tab2, tab3 
WHERE tabl.id = tab2.id 
AND tab2.ref = tab3.id; 
SELECT 
FROM tabl CROSS JOIN tab2 
CROSS JOIN tab3 
WHERE tabl.id = tab2.id 
AND tab2.ref = tab3.id; 
SELECT 
FROM tabl JOIN (tab2 JOIN tab3 
ON (tab2.ref = tab3.id)) 
ON (tabl.id = tab2.id); 


说 穿 了 ， 这 3 个 查询 都 是 相同 的 并 且 会 被 规划 器 以 同样 的 方式 对 待 。 第 一 个 查询 由 
隐 式 连接 组 成 。 最 后 一 个 查询 只 由 显 式 连接 组 成 。 在 内 部 ， 规 划 器 将 检查 那些 请 求 并 且 
相应 地 排序 连接 以 确保 最 好 的 运行 时 间 。 现 在 的 问题 是 ，PostgreSQL 会 暗中 规划 多 少 显 
式 连接 ? 这 正 是 可 以 通过 设置 join_collapse_limit 变量 来 告诉 规划 器 的 信息 ， 其 默认 值 对 
于 普通 查询 已 经 相当 好 了 。 不 过 ， 如 果 用 户 的 查询 包含 数量 很 多 的 连接 ， 使 用 这 个 设置 
可 以 可 观 地 减少 规划 时 间 。 减 少 规划 时 间 对 于 维护 好 的 吞吐 可 能 是 至 关 重要 的 。 

为 了 展示 join_collapse_limit 变量 如 何 改变 计划 ， 笔 者 编写 了 一 个 简单 查询 : 

test=# EXPLAIN WITH x AS (SELECT * FROM generate series(1, 1000) RS id) 

SELECT * 


FROM x AS a JOIN x AS b ON (a.id = b.id) 
JOIN x AS C ON (b.id = c.igd) 
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JOIN x AS d ON (c.id = d.id) 
JOIN x RS ee ON (d.id = e-id) 
JOIN x RS f ON (e.id = f.id); 
尝试 用 不 同 的 设置 运行 该 查询 ， 然 后 看 看 计划 如 何 变 化 。 不 幸 的 是 ， 该 计划 太 长 以 
至 于 无 法 把 它 放 在 这 里 ， 因 此 笔者 无 法 在 本 节 中 展现 实际 的 改变 。 


6.4 启用 和 禁用 优化 器 设置 

















到 目前 为 止 ， 规 划 器 施行 的 大 部 分 重要 优化 已 经 就 或 多 或 少 的 细节 进行 了 讨论 。 
PostgreSQL 这 些 年 来 变 得 越 来 越 聪 明 。 但 仍 有 可 能 出 现 事情 变 得 越 来 越 糟 的 情况 ， 而 用 
户 则 不 得 不 说 服 规划 器 来 做 正确 的 事情 。 

为 了 修改 计划 ，PostgreSQL 提供 了 若干 运行 时 变量 ， 它 们 将 对 规划 产生 显著 的 影 
响 。 其 思想 是 让 最 终 用 户 有 机 会 使 得 计划 中 的 特定 类 型 节点 比 其 他 节点 更 昂贵 。 在 实践 
中 这 意味 着 什么 呢 ? 

这 里 有 一 个 简单 的 计划 : 


test=# explain SELECT * 
FROM generate series(1, 100) AS a, 
generate series(1, 100) AS b 
WHERE a = b; 
QUERY PLAN 
Merge Join (cost=119.66..199.66 rows=5000 width=8) 
Merge Cond: (a.a = b.b) 
-> Sort (cost=59.83. .62.33 rows=1000 width=4) 
Sort Key: a.a 
-> Function Scan on generate series a 
(cost=0.00..10.00 rows=1000 width=4) 
-> Sort (cost=59.83..62.33 rows=1000 width=4) 
Sort Key: b.b 
-> Function Scan on generate series b 
(cost=0.00..10.00 rows=1000 width=4) 
(8 rows) 


该 计划 显示 PostgreSQL 从 函数 读 取 数据 ， 并 且 排 序 两 个 结果 ， 然 后 执行 一 个 归并 
连接 。 

不 过 ， 如 果 归 并 连接 不 是 运行 该 查询 最 快 的 方法 会 怎样 呢 ? 在 PostgreSQL 中 没有 办 
法 像 Oracle 那样 把 规划 器 提示 放 在 注释 中 。 不 过 ， 我 们 可 以 确保 特定 的 查询 会 被 认为 非 
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常 昂贵 。SET enable mergejoin TO o 任 命令 将 会 让 归并 连接 过 于 昂贵 ; 


test=# SET enable mergejoin TO off; 
SET 
test=# explain SELECT * 
FROM generate series(1, 100) AS av 
generate series(1, 100) AS b 
WHERE a=b; 
QUERY PLAN 
Hash Join (cost=22.50..210.00 rows=5000 width=8) 
Hash Cond: (a.a = b.b) 
-> Function Scan on generate series a 
(cost=0.00..10.00 rows=1000 width=4) 
-> Hash (cost=10.00..10.00 rows=1000 width=4) 
-> Function Scan on generate series b 
(cost=0.00..10.00 rows=1000 width=4) 
(5 rows) 


由 于 归并 过 于 昂贵 ，PostgreSQL 决定 尝试 哈 希 连接 。 如 你 所 见 ， 代 价 变 高 了 一 点 ， 
但 由 于 归并 已 不 在 考虑 之 列 ， 所 以 仍然 采用 了 这 个 计划 。 
如 果 哈 希 连接 也 被 关闭 会 发 生 什么 ? 


test=# SET enable hashjoin TO off; 
SET 
test=# explain SELECT * 
FROM generate series(1, 100) AS av 
generate series(1, 100) AS b 
WHERE a=b; 





QUERY PLAN 


Nested Loop (cost=0.01..22510.01 rows=5000 width=8) 
Join Filter: (a.a = b.b) 
-> Function Scan on generate series a 
(cost=0.00..10.00 rows=1000 width=4) 
-> Function Scan on generate series b 
(cost=0.00..10.00 rows=1000 width=4) 


(4 rows) 


PostgreSQL 将 再 次 尝试 其 他 的 东西 ， 并 且 最 后 用 到 了 获 套 循环 。 嵌 套 循环 的 代价 已 
经 令 人 震惊 ， 但 是 规划 器 已 别 无 选择 。 
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如 果 嵌 套 循环 再 被 关闭 会 发 生 什么 ? 


test=# SET enable nestloop TO off; 
SET 
test=# explain SELECT * 
FROM generate series(1, 100) RS a, 
generate series(1, 100) AS b 
WHERE a = b; 
QUERY PLAN 


Nested Loop (cost=10000000000.00..10000022510.00 
rows=5000 width=8) 
Join Filter: (a.a = b.b) 
-> Function Scan on generate series a 
(cost=0.00..10.00 rows=1000 width=4) 
-> Function Scan on generate series b 
(cost=0.00..10.00 rows=1000 width=4) 
(4 rows) 


PostgreSQL 仍 将 执行 戏 套 循环 。 这 里 的 重点 是 这 种 “关闭 ”并 非 真正 意义 上 的 关 
闭 一 一 它 只 是 意味 着 计划 节点 会 被 当 作 一 种 非常 昂贵 的 东西 。 这 一 点 非常 重要 ， 否 则 查 
询 将 无 法 被 执行 。 
有 哪些 设置 可 以 影响 规划 器 ? 有 下 列 开关 可 用 : 
enable bitmapscan = on 
enable hashagg = on 
enable_hashjoin = on 
enable indexscan = on 
enable indexonlyscan = on 
enable material = 
enable mergejoin = on 
enable_nestloop = on 
enable_seqscan = on 
enable sort = on 


enable tidscan = on 

虽然 这 些 设置 绝对 是 有 益 的 ， 但 笔者 想 要 指出 的 是 ， 这 些 调整 应 该 被 非常 非常 小 心 
地 处 理 。 只 用 它们 来 加 速 个 别 查 询 而 不 要 在 全 局 上 去 打开 。 这 些 设置 的 效果 可 能 会 很 快 
就 发 生 反 转 并 且 毁 掉 性 能 。 因 此 ， 在 改变 这 些 参数 之 前 真 的 有 必要 三 思 。 
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@ ”理解 遗传 查询 优化 

规划 处 理 的 结果 是 实现 优秀 性 能 的 关键 。 如 本 章 中 所 示 ， 规 划 不 是 一 件 简单 的 习 
情 ， 并 且 涉 及 多 种 复杂 的 计算 。 一 个 查询 触及 的 表 越 多 ， 规 划 过 程 就 会 变 得 越 复杂 。 有 
越 多 的 表 ， 规 划 器 拥有 的 选择 也 就 更 多 ， 逻 辑 上 规划 时 间 将 会 增加 。 在 某 个 点 上 ， 规 区 
将 会 花费 非常 久 ， 以 至 于 执行 经 典 的 穷 举 搜索 变 得 不 再 可 行 。 除 此 之 外 ， 规 划 时 产 生 的 
错误 也 非常 巨大 ， 总 之 寻找 理论 上 的 最 优 计 划 并 不 一 定 会 得 到 运行 时 间 上 的 最 优 计划 。 

此 时 遗传 查询 优化 《GEQO) 可 以 帮 上 忙 。 什 么 是 GEQO? 其 思想 实际 是 从 自然 界 
借用 过 来 的 ， 它 类 似 于 自然 进化 过 程 。 

PostgreSQL 用 类 似 于 旅行 商 问题 的 方法 来 处 理 GEQO 问题 ， 并 且 把 可 能 的 连接 编码 
为 整数 串 。 例 如 ，4-1-3-2 意味 着 先 连接 4 和 1， 然 后 连接 3， 再 连接 2， 这 些 数 字 表 示 关 
系 的 ID 。 在 最 开始 ， 遗 传 优化 器 将 产生 计划 的 一 个 随机 集合 ， 然 后 检查 那些 计划 。 不 好 
的 计划 会 被 放弃 并 且 会 基于 好 计划 的 基因 生成 新 的 计划 ， 这 种 方式 可 能 会 生成 更 好 的 计 
划 。 这 种 处 理 可 以 被 重复 必要 的 次 数 。 到 了 最 后 ， 将 会 得 到 一 个 计划 ， 它 预期 会 比 使 用 
随机 计划 要 好 得 多 。 

通过 调整 geqo 变量 可 以 打开 和 关闭 GEQO: 

test=# SHOW geqo; 

geqo 





























test=# SET geqo TO off; 
SET 


默认 情况 下 ， 如 果 一 个 语句 超过 一 定 的 复杂 度 ，geqo 就 会 开始 起 作用 ， 这 个 复杂 度 
下 面 的 变量 控制 : 


test=# SHOW geqo threshold ; 
geqo_ threshold 























如 果 用 户 的 查询 大 到 开始 达到 这 一 阔 值 ， 当 然 就 应 该 尝试 一 下 这 个 设置 来 看 看 更 改 
变量 时 规划 器 会 怎样 改变 计划 。 
不 过 ， 一 般 来 说 ， 笔 者 建议 应 该 尽量 避免 使 用 GEQO 并 且 尝 试 通过 使 用 join collapse 
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limit 变量 固定 连接 顺序 来 解决 问题 。 注 意 每 一 个 查询 都 是 不 同 的 ， 因 此 做 实验 和 通过 学 
习 规划 器 在 各 种 情况 下 的 行为 获得 经 验 是 很 有 帮助 的 。 











全 如 果 读者 起 看 看 真正 疯狂 的 连接 ， 可 以 考虑 看 看 笔者 在 Madrid 的 谈话 。 





并 





6.5 分 区 数据 


给 定 默认 的 8000 字 节 块 ，PostgreSQL 可 以 在 单 表 内 存储 多 达 32TB 的 数据 。 如 果 用 户 


用 32000 字 节 块 编译 PostgreSQL， 甚 至 可 以 在 单 表 内 放 进 多 达 128TB。 但 是 ， 那 么 大 的 表 
并 不 一 定 很 方便 ， 因 此 有 必要 对 表 分 区 来 方便 处 理 ， 更 方便 并 且 在 某 些 情况 下 更 快速 。 


从 PostgreSQL 10.0 开始 ， 我 们 将 很 可 能 用 上 改进 过 的 分 区 特性 ， 它 将 为 最 终 用 户 提 


供 更 方便 的 数据 分 区 处 理 。 





在 写作 本 章 时 ，PostgreSQL 10.0 还 没有 被 发 布 ， 因 此 本 章 介绍 的 还 是 旧 的 分 区 方式 。 
6.5.1 创建 分 区 
在 深入 分 区 的 优点 之 前 ， 笔 者 想 要 展示 如 何 创建 分 区 。 整 件 事情 开始 于 一 个 父 表 : 


test=# CREATE TABLE t data (id serial, t date, payload text); 
CREATE TABLE 


在 这 个 例子 中 ， 父 表 有 3 列 。date 列 将 被 用 作 分 区 ， 这 个 稍 后 会 谈 到 更 多 。 
现在 父 表 已 经 就 位 ， 可 以 创建 子 表 。 做 法 如 下 : 
test=# CREATE TABLE t data 2016 () INHERITS (t data); 
CREATE TABLE 
test=# \d t data 2016 
Table "public.t data 2016" 
Column | Type | Modifiers 


id | integer | not null default 
nextval('t data id seq'::regclass) 

下 | date 1 

payload | text 1 

Inherits: 七 data 


这 个 表 被 称 作 t_data 2016， 它 从 t_data 继承 而 来 。0 表 示 没 有 为 子 表 增 加 额外 的 列 。 


如 你 所 见 ， 继 承 意 味 着 来 自 父 表 的 所 有 列 都 在 子 表 中 可 用 。 还 要 注意 id 列 将 继承 来 自 父 
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表 的 序列 ， 因 此 所 有 的 孩子 能 共享 完全 相同 的 编号 。 
让 我 们 创建 更 多 的 表 : 
test=# CREATE TABLE t data 2015 () INHERITS (t data); 
CREATE TABLE 


test=# CREATE TABLE t data 2014 () INHERITS (t data); 
CREATE TABLE 


目前 ， 所 有 的 表 都 是 相同 的 并 且 只 是 从 父 表 继承 。 不 过 ， 其 实 可 以 做 到 更 多 ， 子 表 
实际 上 可 以 有 比 其 父辈 更 多 的 列 。 增 加 更 多 域 很 容易 : 


test=# CREATE TABLE t data 2013 (special text) INHERITS (t data); 
CREATE TABLE 


在 这 种 情况 下 ， 增 加 了 一 个 特殊 列 。 它 对 父 表 没有 影响 ， 只 是 丰富 了 孩子 表 并 且 让 
它们 能 保存 更 多 数据 。 

在 创建 了 一 些 表 后 ， 可 以 增加 一 行 : 

test=# INSERT INTO t data 2015 (t, payload) 


VALUES ('2015-05-04', 'some data'); 
INSERT 0 1 


现在 重头 戏 来 了 ， 父 表 可 以 用 来 查找 子 表 中 所 有 的 数据 : 


test=# SELECT * FROM t data; 


id | 七 | payload 
人 人 
1 1 2015-05-04 | some data 

(1 row) 


查询 父 表 允 许 用 户 以 一 种 简单 且 有 效 的 方式 得 到 父 表 之 下 所 有 子 表 的 访问 。 
要 理解 PostgreSQL 如 何 做 分 区 ， 有 必要 看 看 其 计划 : 


test=# EXPLAIN SELECT * FROM t data; 
QUERY PLAN 
Append (cost=0.00..84.10 rows=4411 width=40) 
-> Seq Scan on t data (cost=0.00..0.00 rows=1 width=40) 
-> Seq Scan on t data 2016 
(cost=0.00..22.00 rows=1200 width=40) 
-> Seq Scan on 七 data 2015 
(cost=0.00. .22.00 rows=1200 width=40) 
-> Seq Scan on t data 2014 
(cost=0.00..22.00 rows=1200 width=40) 
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-> Seq Scan on t data 2013 
(cost=0.00..18.10 rows=810 width=40) 


(6 rows) 


实际 上 ， 该 处 理 非常 简单 。PostgreSQL 简单 地 统一 所 有 的 表 并 且 向 我 们 展示 所 查看 
的 分 区 及 其 下 层 分 区 中 所 有 表 的 全 部 内 容 。 注 意 所 有 的 表 都 是 独立 的 ， 它 们 只 是 通过 系 
统 目录 在 逻辑 上 被 连接 在 一 起 。 


6.5.2 ”应 用 表 约 束 
如 果 应 用 过 滤 条 件 会 发 生 什么 ? 


test=# EXPLAIN SELECT * FROM t data WHERE 七 = '2016-01-04"'; 
QUERY PLAN 
Append (cost=0.00..95.12 rows=23 width=40) 
-> Seq Scan on t data (cost=0.00..0.00 rows=1 width=40) 
Filter: (t = '2016-01-04'::date) 
-> Seq Scan on t data 2016 (cost=0.00..25.00 rows=6 width=40) 
Filter: (t = '2016-01-04'::date) 
-> Seq Scan on t data 2015 (cost=0.00..25.00 rows=6 width=40) 
Filter: (t = '2016-01-04'::date) 
-> Seq Scan on t data 2014 (cost=0.00..25.00 rows=6 width=40) 
Filter: (t = '2016-01-04'::date) 
-> Seq Scan on t data 2013 (cost=0.00..20.12 rows=4 width=40) 
Filter: (t = '2016-01-04'::date) 
(11 rows) 


PostgreSQL 把 过 滤 条 件 应 用 在 该 结构 中 的 所 有 分 区 上 。 它 不 知道 表 名 与 表 的 内 容 有 
某 种 相关 性 。 对 于 数据 库 ， 名 称 只 是 名 称 并 且 与 要 查找 的 东西 没有 关系 。 当 然 ， 这 很 容 
易 理解 ， 因 为 没有 数学 证 明 可 以 用 来 做 别 的 事情 。 

现在 的 问题 是 ， 我 们 怎么 才能 让 数据 库 知道 2016 表 只 包含 2016 的 数据 ，2015 表 只 
包含 2015 的 数据 等 ? 表 约 束 就 是 这 个 用 途 的 。 它 们 会 告诉 PostgreSQL 那些 表 的 内 容 ， 因 
此 让 规划 器 做 出 比 以 前 更 聪明 的 决定 。 这 种 特性 被 称 为 约束 排除 ， 它 能 在 很 多 情况 下 极 
大 地 加 速 查询 。 

下 面 的 列表 展示 了 如 何 创建 表 约 束 : 

test=# ALTER TABLE t data 2013 

ADD CHECK (t < '2014-=01-01°'); 


ALTER TABLE 
test=# ALTER TABLE t data 2014 
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ADD CHECK (t >= "2014-01-01' AND t < '2015-01-01°'); 
ALTER TABLE 
test=# ALTER TABLE t data 2015 

ADD CHECK (t >= "2015-=01-01" AND 七 < "2016=01=017)7 
ALTER TABLE 
test=# ALTER TABLE t data 2016 

ADD CHECK (t >= "2016-01-01” AND 七 < ’2017-01-01°'); 
ALTER TABLE 


每 个 表 都 可 以 增加 一 个 CHECK 约束 。 


PostgreSQL 只 会 在 那些 表 中 的 所 有 数据 都 完全 正确 且 每 一 行 都 满足 约束 时 
EE 创建 约束 。 与 MySQL 不 同 ，PostgreSQL 中 的 约束 在 任何 环境 下 都 会 被 严肃 对 
待 和 遵循 。 


在 PostgreSQL 中 ， 那 些 约束 可 以 重合 一 一 这 并 未 被 禁止 并 且 可 以 在 一 些 情况 下 有 意 
义 。 不 过 ,创建 非 重 县 的 约束 一 般 来 说 会 更 好 ， 因 为 PostgreSQL 可 以 前 枝 更 多 表 。 
下 面 是 增加 了 那些 表 约 束 后 的 效果 
test=# EXPLAIN SELECT * 
FROM t data 
WHERE t = '2016-01-04"; 
QUERY PLAN 


Append (cost=0.00..25.00 rows=7 width=40) 
-> Seq Scan on t data (cost=0.00..0.00 rows=1 width=40) 
Filter: (t = '2016-01-04'::date) 
-> Seq Scan on t data 2016 (cost=0.00..25.00 rows=6 width=40) 
Filter: (t = '2016-01-04'::date) 
(5 rows) 


规划 器 能 够 从 查询 中 移 除 很 多 表 ， 并 且 只 保留 那些 可 能 会 包含 数据 的 表 。 查 询 可 以 


从 一 个 更 短 、 更 有 效 的 计划 中 大 大 受益 。 尤 其 是 如 果 那 些 表 确 实 很 大 时 ， 移 除 它们 可 以 
非常 可 观 地 提高 速度 。 


6.5.3 ”修改 继承 的 结构 


有 时 数据 结构 必须 被 修改 ，“ALTER TABLE” 子 句 就 是 做 这 个 的 。 问 题 是 怎么 修改 
被 分 区 的 表 ? 
基本 上 所 有 要 做 的 事情 就 是 处 理 父 表 并 且 增 加 或 者 移 除 列 。PostgreSQL 自动 地 把 那 
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些 更 改 传播 到 子 表 并 且 确 保 那些 更 改 被 应 用 于 所 有 的 关系 : 


test=# ALTER TABLE t data ADD COLUMN x int; 
ALTER TABLE 
test=# \d t data 2016 

Table "public.t data 2016" 


Column | Type | Modifiers 
se 让 
id | integer | not null default 
nextval('t data id seq'::regclass) 
| date | 
payload | text 1 
9 | integer | 


Check constraints: 

"t data 2016 t check" 

CHECK (t >= "2016-01-01'::date AND t < '2017-01-01'::date) 
Inherits: t data 
如 你 所 见 ， 列 被 增加 到 父 表 并 且 被 自动 地 增加 到 子 表 上 。 
注意 这 种 方式 对 列 之 类 的 东西 都 有 效 ， 但 索引 则 完全 是 另外 一 码 事 。 在 继承 结构 中 ， 
每 一 个 表 都 必须 被 单独 索引 。 如 果 对 父 表 增 加 一 个 索引 ， 它 只 会 出 现在 父 表 上 一 一 而 不 会 
被 部 署 在 那些 子 表 上 。 在 所 有 那些 表 中 索引 所 有 那些 列 是 用 户 的 任务 ，PostgreSQL 不 会 帮 
用 户 做 那些 决定 。 当 然 ， 这 可 以 被 视 作 一 种 特性 或 者 一 种 限制 。 从 好 的 方面 看 ， 我 们 可 
以 说 PostgreSQL 给 了 用 户 所 有 灵活 性 来 单独 索引 表 ， 可 能 效率 因此 更 好 。 但 是 ， 人 们 可 
能 也 有 争议 ， 逐 个 部 署 所 有 这 些 索 引 的 工作 量 太 大 。 


6.5.4 ”在 分 区 结构 中 移 进 和 移出 表 


假定 有 一 个 继承 结构 ， 数 据 被 按照 日 期 分 区 并 且 想 要 对 最 终 用 户 提供 最 近 几 年 的 数 
据 。 在 某 一 时 刻 ， 用 户 可 能 想 要 把 一 些 数据 移出 用 户 的 视线 而 不 实际 触 碰 到 数据 。 用 户 
还 可 以 把 数据 放 入 某 种 归档 等 。 

PostgreSQL 提供 了 一 种 简单 的 方式 来 实现 这 一 需求 。 首 先 可 以 创建 一 个 新 的 父 表 

test=# CREATE TABLE t history (LIKE t data); 

CREATE TABLE 

LIKE 关键 词 允许 用 户 创建 一 个 和 t_data 表 具 有 完全 相同 布局 的 表 。 在 忘记 了 t_data 
表 实 际 有 哪些 列 的 情况 下 ， 这 会 非常 方便 ， 因 为 它 减少 了 很 多 工作 量 。 这 种 方式 还 可 以 
包括 索引 、 约 束 和 默认 值 。 

然后 可 以 从 旧 的 父 表 移 除 表 并 且 把 它们 放 在 新 的 父 表 之 下 。 
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做 法 如 下 : 


test=# ALTER TABLE t data 2013 NO INHERIT t data; 
ALTER TABLE 
test=# ALTER TABLE t data 2013 INHERIT t history; 
ALTER TABLE 


当然 可 以 把 整个 处 理 放 在 一 个 事务 中 以 确保 操作 的 原子 性 。 
6.5.5 ”清理 数据 


分 区 表 的 一 个 优点 是 可 以 快速 清理 数据 。 假 定 我 们 想 要 删除 一 整 年 的 数据 ， 如 果 数 
据 已 经 被 相应 地 分 区 好 ， 用 一 个 简单 的 DROP TABLE 子 句 就 能 完成 这 一 任务 : 


test=# DROP TABLE t data 2014; 
DROP TABLE 


如 你 所 见 ， 删 除 一 个 子 表 很 容易 。 但 是 删除 父 表 会 怎样 呢 ? 由 于 有 依赖 对 象 存在 ， 
对 此 PostgreSQL 自然 会 报错 来 确保 不 会 发 生意 外 : 


test=# DROP TABLE t data; 

ERROR: cannot drop table t data because other objects depend on it 

DETAIL: default for table t data 2013 column id depends on 
sequence t data id seq 

table t data 2016 depends on table t data 

table t data 2015 depends on table t data 

HINT: Use DROP ... CASCADE to drop the dependent objects too. 


“DROP TABLE” 子 句 会 警告 有 依赖 对 象 存 在 且 拒绝 删除 的 那些 表 。 强 制 PostgreSQL 
把 那些 对 象 和 父 表 一 起 实际 地 删除 ， 需 要 CASCADE 子 句 : 


test=# DROP TABLE t data CASCADE; 

NOTICE: drop cascades to 3 other objects 

DETAIL: drop cascades to default for table t data 2013 column id 
drop cascades to table t data 2016 

drop cascades to table t data 2015 

DROP TABLE 





轩 





6.6 为 好 的 查询 性 能 调整 参数 


编写 好 的 查询 是 达到 好 性 能 的 第 一 步 。 没 有 好 的 查询 ， 用 户 很 可 能 会 被 不 好 的 性 能 
折磨 。 因 此 ， 编 写 好 的 并 且 聪 明 的 代码 将 让 用 户 更 有 可 能 得 到 好 的 性 能 。 一 旦 查询 已 经 
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从 逻辑 和 语义 的 角度 完成 优化 ， 好 的 内 存 设 置 将 提供 最 终 的 加 速 。 在 本 节 中 ， 读 者 将 学 
到 更 多 的 内 存 能 为 我 们 做 什么 以 及 PostgreSQL 能 怎样 利用 它 来 让 我 们 受益 。 
为 了 说 明 问 题 ， 笔 者 编 了 一 个 简单 的 例子 : 


test=# CREATE TABLE t test (id serial, name text); 

CREATE TABLE 

test=# INSERT INTO t test (name) SELECT '‘'hans' 
FROM generate series(1, 100000); 

INSERT 0 100000 

test=# INSERT INTO t test (name) SELECT "paul" 
FROM generate series(1, 100000); 

INSERT 0 100000 


一 百 万 个 包含 hans 的 行将 被 增加 到 表 中 ， 然 后 一 百 万 个 包含 paul 的 行 被 载 入 。 表 中 
将 总 共有 两 百 万 个 唯一 的 ID， 但 是 只 有 两 种 不 同 的 名 字 。 

现在 让 我 们 使 用 PostgreSQL 的 默认 内 存 设置 运行 一 个 简单 的 查询 : 

test=# SELECT name, count (*) FROM 七 test GROUP BY 1; 

name | count 

Es a 

hans | 100000 


paul | 100000 
(2 rows) 


不 出 意外 ， 有 两 行将 被 返回 。 但 这 里 的 重点 不 是 结果 ， 而 是 PostgreSQL 在 幕后 做 了 
什么 : 
test=# EXPLAIN ANALYZE SELECT name, count(*) 


FROM t test 
GROUP BY 1; 





QUERY PLAN 
HashAggregate (cost=4082.00..4082.01 rows=1 width=13) 
(actual time=51.448..51.448 rows=2 loops=1) 
Group Key: name 
-> Seq Scan on t test 
(cost=0.00..3082.00 rows=200000 width=5) 
(actual time=0.007..14.150 rows=200000 loops=1) 
Planning time: 0.032 ms 
Execution time: 51.471 ms 
(5 rows) 
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PostgreSQL 发 现 分 组 的 数目 实际 上 非常 小 。 因 此 ， 它 创建 了 一 个 哈 希 表 ， 并 且 为 每 





个 分 组 加 入 了 一 个 哈 希 项 ， 然 后 开始 计数 。 由 于 分 组 数量 低 ， 哈 希 表 其 实 很 小 并 且 
PostgreSQL 能 够 很 快 地 通过 为 每 个 分 组 增加 数字 完成 计数 。 


如 果 通 过 id 而 不 是 name 分 组 会 发 生 什 么 ? 分 组 的 数量 将 会 诡 升 : 


test=# EXPLAIN ANALYZE SELECT id, count(*) 

FROM 七 test 

GROUP BY 1; 

QUERY PLAN 

GroupAggregate (cost=23428.64..26928.64 rows=200000 width=12) 
(actual time=97.128..154.205 rows=200000 loops=1) 
Group Key: id 

-> Sort (cost=23428.64..23928.64 rows=200000 width=4) 
(actual time=97.120..113.017 rows=200000 loops=1) 
Sort Key: id 

Sort Method: external sort Disk: 2736kB 

-> Seq Scan on t test 

(cost=0.00..3082.00 rows=200000 width=4) 

(actual time=0.017..19.469 rows=200000 loops=1) 
Planning time: 0.128 ms 

Execution time: 160.589 ms 

(8 rows) 


PostgreSQL 发 现 分 组 数 现在 大 了 很 多 ， 于 是 很 快 地 改变 了 它 的 策略 。 问 题 是 一 个 包 


含 如 此 多 项 的 哈 希 表 无 法 放 入 内 存 中 : 


test=# SHOW work mem ; 
work mem 


(1 row) 


work mem 变量 掌管 着 GROUP BY 子 句 使 用 的 哈 希 表 尺寸 。 由 于 有 太 多 项 ， 

















PostgreSQL 不 得 不 找到 一 种 不 需要 将 整个 数据 集 保持 在 内 存 中 的 策略 。 解 决 方案 是 按照 
ID 排序 数据 并 且 将 其 分 组 。 一 旦 数据 被 排序 好 ，PostgreSQL 就 能 在 列表 中 下 移 ， 然 后 一 
个 接 一 个 地 构造 分 组 。 如 果 第 一 类 值 被 计数 完 ， 则 部 分 结果 已 经 被 算出 并 且 可 以 被 发 


出 。 


现 ， 








然后 可 以 处 理 下 一 个 分 组 。 在 下 移 时 一 旦 有 序列 表 中 的 值 改变 ， 它 就 绝 不 会 再 次 出 
为 此 系统 知道 一 个 部 分 结果 已 经 准备 好 。 
为 了 加 速 该 查询 ， 可 以 临时 《当然 ， 也 可 以 从 全 局 设置 ) 为 work mem 变量 设置 一 
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个 较 高 的 值 : 


test=# SET work mem TO "1 GB'; 
SET 


现在 计划 将 再 次 由 一 个 快速 且 有 效 的 哈 希 聚 集 唱主角 : 


test=# EXPLAIN ANALYZE SELECT id, count(*) FROM t test GROUP BY 1; 
QUERY PLAN 





HashAggregate (cost=4082.00..6082.00 rows=200000 width=12) 
(actual time=76.967..118.926 rows=200000 loops=1) 
Group Key: id 
-> Seq Scan on t test 
(cost=0.00..3082.00 rows=200000 width=4) 
(actual time=0.008..13.570 rows=200000 loops=1) 
Planning time: 0.073 ms 
Execution time: 126.456 ms 
(5 rows) 


PostgreSQL 知道 (或 者 至 少 会 假设 ) 数据 将 适合 于 内 存 并 且 切 换 到 较 快 的 计划 。 如 
你 所 见 ， 执 行 时 间 变 得 更 低 。 该 查询 不 会 和 “GROUP BY name” 情 况 一 样 快 ， 因 为 不 得 
不 计算 更 多 的 哈 希 值 ， 但 用 户 在 绝 大 多 数 情况 下 都 将 从 中 受益 。 


6.6.1 加 速 排序 


work_mem 变量 不 仅 能 加 速 分 组 ， 还 能 对 排序 等 简单 的 操作 产生 非常 好 的 影响 。 排 序 
可 以 说 是 世界 上 每 一 个 数据 库 系 统 都 要 掌握 的 核心 机 制 。 

下 列 查 询 展 示 了 一 个 使 用 默认 4MB 设置 的 简单 操作 : 

test=# SET work mem TO default; 

SET 


test=# EXPLAIN ANALYZE SELECT * FROM t test ORDER BY name, id; 
QUERY PLAN 








Sort (cost=24111.14..24611.14 rows=200000 width=9) 
(actual time=219.298..235.008 rows=200000 loops=1) 
Sort Key: name, id 

Sort Method: external sort Disk: 3712kB 

-> Se6dq Secan on tteat 

(cost=0.00..3082.00 rows=200000 width=9) 

(actual time=0.006..13.807 rows=200000 loops=1) 
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Planning time: 0.064 ms 
Execution time: 241.375 ms 


(6 rows) 


PostgreSQL 需要 13.8 毫秒 来 读 取 数据 ， 并 且 需 要 超过 200 毫秒 来 排序 数据 。 





RAM， 但 必须 把 中 间 数 据 发 送 到 相对 较 慢 的 存储 设备 ， 这 当然 会 导致 可 怜 的 吞吐 。 
增加 work_mem 变量 的 设置 将 让 PostgreSQL 使 用 更 多 内 存 排序 : 


test=# SET work mem TO "1 GB'; 
SET 
test=# EXPLAIN ANALYZE SELECT * FROM t test ORDER BY name, id; 
QUERY PLAN 

Sort (cost=20691.64..21191.64 rows=200000 width=9) 
(actual time=36.481..47.899 rows=200000 loops=1) 
Sort Key: name, id 

Sort Method: quicksort Memory: 15520kB 

-> Seq Scan on 七 test 

(cost=0.00..3082.00 rows=200000 width=9) 

(actual time=0.010..14.232 rows=200000 loops=1) 
Planning time: 0.037 ms 

Execution time: 55.520 ms 
(6 rows) 
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于 可 











用 的 内 存量 低 ， 必 须 使 用 临时 文件 来 执行 排序 。external sort Disk 方法 只 需要 少量 的 


] 于 现在 有 足够 的 内 存 ， 数 据 库 将 在 内 存 中 做 所 有 的 排序 并 且 因此 会 极 大 地 提高 处 


理 速度 。 现 在 排序 只 需要 33 毫秒 ， 这 比 之 前 查询 提升 了 7 倍 。 更 多 的 内 存 将 导致 更 快 的 


排序 并 且 提高 系统 的 速度 。 


到 目前 为 止 ， 读 者 已 经 看 到 了 两 种 排序 数据 的 机 制 : external sort Disk 和 quicksort 
Memory。 除 这 两 种 机 制 之 外 ， 还 有 第 三 种 算法 ， 它 是 “top-N heapsort Memory”。 它 只 


能 被 用 来 提供 前 N 行 : 

test=# EXPLAIN ANALYZE SELECT * 

FROM t test 

ORDER BY name, id 

LIMIT 10; 

QUERY PLAN 

Limit (cost=7403.93..7403.95 rows=10 width=9) 
(actual time=31.837..31.838 rows=10 loops=1) 

-> Sort (cost=7403.93..7903.93 rows=200000 width=9) 


* 164° 由 浅 入 深 PostereSQL 


(actual time=31.836..31.837 rows=10 loops=1) 

Sort Key: name, id 

Sort Method: top-N heapsort Memory: 25kB 

=> Seq Scan on t test 

(cost=0.00..3082.00 rows=200000 width=9) 

(actual time=0.011..13.645 rows=200000 loops=1) 

Planning time: 0.053 ms 

Execution time: 31.856 ms 

(7 rows) 

该 算法 快 如 闪电 ， 整 个 查询 将 在 比 30 毫秒 略 多 的 时 间 内 完成 。 排 序 部 分 现在 只 需要 
18 毫秒 ， 这 几乎 和 第 一 种 情况 中 读 取 数据 一 样 快 。 
注意 ，work_mem 变量 是 对 每 个 操作 分 配 的 。 理 论 上 会 发 生 一 个 查询 需要 多 于 一 次 的 
work_mem 变量 。 它 不 是 一 个 全 局 设置 一 一 它 实际 上 是 针对 每 个 操作 的 。 因 此 必须 以 一 种 
小 心 的 方式 设置 它 。 

读者 应 该 记 住 一 件 事情 ， 很 多 书籍 声称 在 OLTP 系统 上 将 work_mem 设置 得 过 高 可 
能 会 导致 服务 器 内 存 不 足 。 是 的 ， 如 果 1000 个 人 同时 排序 100MB 数据 ， 就 会 导致 内 存 
失效 。 但 是 ， 磁 盘 能 够 处 理 这 么 大 的 数据 量 吗 ? 笔者 很 怀疑 。 解 决 方案 只 能 是 : 停止 做 
昌 春 的 事情 。 无 论 如 何 ， 并 发 地 排序 100MB 数据 1000 次 不 应 该 是 一 个 OLTP 系统 中 应 
该 发 生 的 事情 。 应 该 考虑 部 署 合适 的 索引 、 编 写 更 好 的 查询 或 者 简单 地 重新 思考 所 面 对 
的 需求 。 在 任何 情况 下 ， 过 于 频繁 地 并 发 排序 那么 大 量 的 数据 都 不 是 什么 好 主意 一 一 在 
那些 事情 造成 应 用 停摆 之 前 赶快 停 下 来 。 


6.6.2 ”加 速 管理 任务 
还 有 更 多 操作 不 得 不 做 某 种 排序 或 者 某 种 类 型 的 内 存 分 配 。CREATE INDEX 子 句 之 类 
的 管理 操作 不 依赖 于 work_mem 变量 ， 而 是 使 用 maintenance work_mem 变量 。 用 法 如 下 : 


test=# SET maintenance work mem TO '1 MB'; 
SET 
test=# \timing 

















Timing is on. 

test=# CREATE INDEX idx id ON t test (id); 

CREATE INDEX 

Time: 104.268 ms 

如 你 所 见 ， 在 两 百 万 行 上 创建 一 个 索引 花 了 大 约 100 毫秒 ， 这 个 速度 确实 有 点 慢 。 
因此 ， 可 以 用 maintenance work_mem 变量 来 加 速 排序 ， 而 “CREATE INDEX” 子 句 本 质 
上 就 依赖 于 排序 : 
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test=# SET maintenance work mem 0. NIG 
SET 

test=# CREATE INDEX idx id2 ON t test (id); 
CREATE INDEX 

Time: 46.774 ms 


现在 的 速度 翻 了 一 倍 ， 正 是 因为 排序 被 提升 了 那么 多 。 

还 有 更 多 管理 任务 会 从 使 用 更 多 内 存 中 受益 ， 最 突出 的 是 VACUUM 子 句 〈 清 除 索 
引 ) 和 ALTER TABLE 子 句 。maintenance work mem 变量 的 规则 与 work mem 变量 相 
同 。 设 置 是 针对 每 个 操作 的 ， 并 且 所 需 内 存 只 在 使 用 时 才 分 配 。 





6:7 总 结 


在 本 章 中 讨论 了 许多 查询 优化 。 读 者 学 到 了 有 关 优化 器 和 多 种 内 部 优化 的 内 容 ， 例 
如 常数 折 登 、 视 图 内 联 、 连 接 等 。 所 有 这 些 优化 都 有 助 于 好 的 性 能 ， 并 且 能 够 可 观 地 提 

在 介绍 了 优化 之 后 ， 第 7 章 将 涉及 存储 过 程 。 读 者 将 看 到 PostgreSQL 用 于 处 理 用 户 
定义 代码 的 选项 。 


第 7 章 编写 存储 过 程 


在 第 6 章 中 ， 读 者 已 经 学 到 了 很 多 有 关 优 化 器 的 内 容 以 及 系统 中 所 进行 的 优化 。 本 
章 将 介绍 存储 过 程 以 及 如 何 有 效 和 方便 地 使 用 它们 。 读 者 将 学 到 存储 过 程 的 构成 、 可 用 
的 语言 以 及 如 何 很 好 地 提高 它们 的 速度 。 除 此 之 外 ， 读 者 还 将 了 解 PL/pgSQL 的 一 些 更 高 
级 的 特性 。 

本 章 将 涵盖 下 列 内 容 : 

@ 决定 正确 的 语言 。 
存储 过 程 如 何 被 执行 。 
PL/pgSQL 的 高 级 特性 。 
打包 扩展 。 
优化 性 能 。 
配置 函数 参数 。 
在 本 章 结束 时 ， 读 者 将 能 够 编写 优秀 且 高 效 的 过 程 。 


7.1 理解 存储 过 程 语言 





在 存储 过 程 方面 ，PostgreSQL 和 其 他 数据 库 系 统 有 相当 显著 的 区 别 。 大 部 分 数据 库 
引擎 强制 用 户 使 用 一 种 特定 的 编程 语言 来 编写 服务 器 端的 代码 。 微 软 SQL Server 提供 了 
Transact-SQL， 而 Oracle 鼓励 用 户 使 用 PL/SQL。PostgreSQL 不 强制 用 户 使 用 一 种 特定 的 
语言 ， 而 是 允许 用 户 决定 自己 最 了 解 以 及 最 喜欢 的 语言 。 

在 历史 上 ，PostgreSQL 如 此 灵活 的 原因 实际 上 也 非常 有 趣 。 很 多 年 前 ， 最 有 名 的 
PostgreSQL 开发 者 之 一 〈Jan Wieck， 在 早期 编写 了 无 数 的 补丁 ) 提出 了 用 TCL 作为 服务 
器 端 编程 语言 的 想法 。 但 问题 很 简单 一 一 没有 人 想 用 TCL 并 且 没 有 人 想 在 数据 库 引 擎 里 
加 上 它 。 对 于 这 个 问题 的 解决 方案 就 变 成 了 让 语言 接口 如 此 灵活 的 现状 ， 基 本 上 任何 语言 
都 可 以 很 容易 地 与 PostgreSQL 整合 起 来 。 然 后 ， CREATE LANGUAGE 子 句 便 诞生 了 : 

test=# h CREATE LANGUAGE 

Command: CREATE LANGUAGE 


Description: define a new procedural language 








Syntax: 
CREATE [ OR REPLACE ] [ PROCEDURAL ] LANGUAGE name 
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CREATE [ OR REPLACE ] [ TRUSTED ] [ PROCEDURAL ] LANGUAGE name 
HANDLER call handler [ INLINE inline handler ] 
[ VALIDATOR valfunction ] 


现 如 今 ， 很 多 不 同 的 语言 都 可 以 被 用 来 编写 存储 过 程 。 早 期 加 入 PostgreSQL 的 这 种 
灵活 性 确实 取得 了 成 功 ， 因 此 用 户 可 以 从 丰富 的 编程 语言 集合 中 进行 选择 。 
PostgreSQL 到 底 是 怎样 处 理 语言 的 ? 如 果 读 者 看 一 看 CREATE LANGUAGE 子 句 的 
语法 ， 那 么 就 能 看 到 几 个 关键 词 。 
@ HANDLER: 这 个 函数 实际 上 就 是 PostgreSQL 和 任何 想 要 使 用 的 外 部 语言 之 间 
的 粘 合剂 。 它 负责 将 PostgreSQL 数据 结构 映射 到 语言 所 需 的 结构 并 且 帮 助 传递 
给 代码 。 
@ VALIDATOR: 这 是 整个 架构 中 的 警察 。 如 果 这 个 部 件 可 用 ， 它 负责 将 语法 错误 
递送 给 最 终 用 户 。 很 多 语言 都 能 够 在 真正 执行 代码 前 先 解析 它 。PostgreSQL 可 
以 使 用 这 一 点 并 且 在 创建 函数 时 告诉 用 户 它 是 否 正确 。 不 幸 的 是 ， 并 非 所 有 的 
语言 都 能 这 样 做 ， 因 此 在 某 些 情 况 下 ， 问 题 只 会 在 运行 时 出 现 。 
@ INLINE: 如 果 它 存在 ，PostgreSQL 将 能 够 在 这 个 函数 内 运行 匿名 代码 块 。 
@ 存储 过 程 剖析 
在 实际 深入 一 种 特定 语言 之 前 ， 笔 者 想 先 谈 谈 存 储 过 程 的 典型 构造 。 为 了 演示 ， 笔 
者 已 经 编写 好 了 一 个 函数 ， 它 只 是 将 两 个 数 加 起 来 : 
test=# CREATE OR REPLACE FUNCTION mysum(int, int) 
RETURNS int AS 


SELECT $1 + $2; 
' LANGUAGE 'sql'; 
CREATE FUNCTION 
可 以 看 到 的 第 一 点 是 ， 该 过 程 采用 SQL 编写 。PostgreSQL 必须 知道 我 们 使 用 哪 种 语 
言 ， 因 此 我 们 必须 在 定义 中 指定 这 一 点 。 注 意 该 函数 的 代码 被 作为 一 个 字符 串 〈') 传递 
给 PostgreSQL 。 这 是 值得 注意 的 地 方 ， 因 为 这 样 做 会 把 函数 当 作 一 个 黑 盒 交 给 执行 机 
制 。 在 其 他 数据 库 引 擎 中 ， 函 数 的 代码 不 是 字符 串 ， 而 是 直接 附 在 语句 中 。 这 种 简单 的 
抽象 层 就 是 PostgreSQL 函数 管理 器 的 力量 来 源 。 

在 该 字符 串 中 ， 用 户 基本 上 可 以 使 用 所 有 的 编程 语言 。 在 笔者 的 例子 中 ， 笔 者 只 是 
简单 地 将 传递 给 函数 的 两 个 数 加 起 来 。 对 于 这 个 例子 ， 用 到 了 两 个 整数 变量 。 这 里 的 重 
点 是 PostgreSQL 提供 了 函数 重 载 。 换 句 话 说 ，mysum(inb inD 和 mysum(int8, int8) 是 不 同 
的 函数 ，PostgreSQL 将 这 些 东西 视 作 两 个 不 同 的 函数 。 虽 然 函 数 重 载 是 一 种 很 好 的 特 
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性 ， 但 是 ， 如 果 用 户 的 函数 参数 列表 碰巧 会 随时 间 变 化 ， 那 么 就 要 非常 小 心 不 要 部 署 过 
多 函数 。 一 定 要 确保 删除 不 再 需要 的 函数 。 
CREATE OR REPLACE FUNCTION 子 句 将 不 会 更 改 参 数列 表 。 因 此 ， 只 
有 签名 没有 改变 时 才能 使 用 它 。 它 将 报 出 错误 或 者 简单 地 部 署 一 个 新 的 函数 。 
让 我 们 运行 这 个 函数 : 
test=# SELECT mysum(10, 20); 
mysum 





(1 row) 
结果 确实 没什么 稀奇 的 。 
1. 引入 美元 符号 引用 


将 代码 作为 字符 串 传 递 给 PostgreSQL 非常 灵活 。 但 是 ， 使 用 单 引 号 可 能 会 是 一 个 问 
题 。 在 很 多 编程 语言 中 ， 单 引号 会 很 频繁 地 出 现 。 为 了 能 够 使 用 引号 ， 人 们 不 得 不 在 将 
字符 串 传 递 给 PostgreSQL 时 对 它们 转 义 。 很 多 年 来 ， 这 都 是 标准 程序 。 幸 运 的 是 ， 旧 时 
代 已 经 过 去 ， 现 在 有 新 方法 可 以 传递 代码 给 PostgreSQL: 

test=# CREATE OR REPLACE FUNCTION mysum(int，int) 

RETURNS int AS 

$$ 

SELECT $1 + $2; 
$$ LANGUAGE 'sql'; 
CREATE FUNCTION 


字符 串 引 用 问题 的 解决 方案 被 称 作 美元 引用 。 除 了 使 用 引号 开始 和 结束 字符 串 之 
外 ， 用 户 还 可 以 使 用 $$。 当 前 ， 笔 者 只 发 现 两 种 语言 为 8$ 赋 予 了 含义 。 在 Perl 以 及 bash 
脚本 中 ，$$ 表 示 进 程 DD。 为 了 克服 这 个 小 障碍 ， 用 户 可 以 使 用 “$ 几 乎 所 有 东西 $” 来 开 
始 和 结束 字符 串 。 下 面 的 例子 演示 了 这 种 用 法 : 

test=# CREATE OR REPLACE FUNCTION mysum(int, int) 


RETURNS int AS 
SS 





SELECT $1 + $2; 
$$ LANGUAGE 'sql'; 
CREATE FUNCTION 
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所 有 这 种 灵活 性 允许 用 户 真正 一 劳 永 逸 地 克服 引用 的 问题 。 只 要 开始 字符 串 和 结束 
字符 串 匹 配 ， 就 不 会 有 任何 问题 。 


2， 使 用 匿名 代码 块 


到 目前 为 止 ， 读 者 已 经 学 到 了 编写 最 简单 的 存储 过 程 以 及 执行 代码 。 但 是 代码 执行 
中 不 仅仅 只 有 典型 的 存储 过 程 。 除 典型 的 存储 过 程 之 外 ，PostgreSQL 还 允许 使 用 匿名 代 
码 块 。 其 思想 是 运行 只 需要 一 次 的 代码 。 这 种 代码 执行 在 处 理 管理 任务 时 尤其 有 用 。 匿 
名 代码 块 没有 参数 ， 并 且 不 会 被 持久 存储 在 数据 库 中 ， 因 为 不 管 怎样 它们 都 不 会 有 名 字 。 
这 里 有 一 个 简单 的 例子 : 
test=# DO 
$5 
BEGIN 
RAISE NOTICE '‘'current time: $', now(); 
END; 
$$ LANGUAGE '‘'plpgsql'; 
NOTICE: current time: 2016-12-12 15:25:50.678922+01 


CONTEXT: PL/pgSQL function inline code block line 3 at RAISE 
DO 


在 这 个 例子 中 ， 代 码 只 是 发 出 一 个 消息 并 且 退 出 。 同 样 ， 代 码 块 必 须知 道 它 使 用 哪 
种 语言 。 字 符 串 也 再 次 通过 使 用 简单 的 美元 引用 传递 给 PostgreSQL。 


3 使 用 函数 和 事务 


如 你 所 知 ，PostgreSQL 暴露 在 用 户 空间 的 所 有 东西 都 是 一 个 事务 。 当 然 ， 编 写 存储 
过 程 时 也 是 一 样 。 过 程 总 是 所 在 的 事务 的 一 部 分 ， 它 不 是 自治 的 一 一 它 就 像 一 个 操作 符 
或 者 任何 其 他 操作 。 

这 里 是 一 个 例子 : 


test=# SELECT now(), mysum(id, id) FROM generate series(1, 3) AS id; 
now | mysum 


2Z016=12=12 152854532520702750L 
O06=12=12 .15:54532.20702710. 
2016=12=12 15:54:325287102710L 
(3 rows) 


所 有 3 个 函数 调用 都 发 生 在 同一 个 事务 中 。 理 解 这 一 点 很 重要 ， 因 为 它 意味 着 在 一 
个 函数 内 无 法 做 太 多 事务 性 的 流程 控制 。 假 定 第 二 个 函数 调用 提交 ， 这 种 情况 下 会 发 生 
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什么 ? 这 样 是 无 法 工作 的 。 

但 是 Oracle 有 一 种 机 制 允 许 自治 事务 。 其 想法 是 如 果 一 个 事务 回 滨 ， 某 些 部 分 可 能 
仍 被 需要 并 且 应 该 被 保留 。 经 典 的 例子 如 下 : 

@ ”开始 一 个 函数 查找 秘密 数据 。 

@ ”在 文档 中 增加 一 个 日 志 行 说 明 有 人 已 经 修改 了 这 个 重要 的 秘密 数据 。 

@ 提交 日 志 行 但 是 回 滚 更 改 。 

@ 仍 需要 知道 某 人 尝试 过 更 改 数据 。 

要 解决 这 样 的 问题 ， 可 以 使 用 自治 事务 。 其 思想 是 在 主事 务 内 独立 地 提交 一 个 事 
务 。 在 这 种 情况 下 ， 日 志 表 中 的 项 将 留 下 来 而 更 改 将 被 回 滚 。 

截至 PostgreSQL 9.6， 自 治 事务 还 没有 出 现 。 但 是 ， 笔 者 已 经 见 过 一 些 实现 这 一 特性 
的 补丁 到 处 流传 。 至 于 这 些 特性 何 时 会 被 放 到 核心 中 ， 就 让 我 们 拭目以待 吧 。 

为 了 让 读者 对 这 些 特性 有 些 印 象 ， 这 里 有 一 个 基于 第 一 批 补丁 的 代码 片段 : 




















AS $$ 
DECLARE 
PRAGMA AUTONOMOUS TRANSACTION; 
BEGIN 
FOR i IN 0..9 LOOP 
START TRANSACTION; 
INSERT INTO test1l VALUES (i); 
IE i % 2 = 0 THEN 
COMMIT; 
ELSE 
ROLLBACK; 
END IF; 
END LOOP; 


RETURN 42; 
END; 
$8; 





这 个 例子 中 的 重点 是 ， 我 们 可 以 临时 决定 提交 或 者 回 滚 自治 事务 。 
7.2 ”理解 各 种 存储 过 程 语 言 


正如 本 章 开始 时 所 述 ，PostgreSQL 让 用 户 能 够 使 用 多 种 语言 编写 存储 过 程 。PostgreSQL 
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核心 包含 了 下 列 选项 : 

© SQL 
PL/pgSQL 
PL/Perl 和 PL/PerlU 
PL/Python 
PL/Tcl 和 PL/TclU 

SQL 是 编写 存储 过 程 最 显而易见 的 选择 ， 应 该 尽 可 能 使 用 它 ， 因 为 它 为 优化 器 提供 
了 最 大 的 自由 度 。 不 过 ， 如 果 用 户 想 要 编写 更 加 复杂 的 代码 ，PL/pgSQL 可 能 是 一 种 选 
择 。 它 提供 了 流程 控制 和 更 多 的 特性 。 本 章 将 展示 PL/pgSQL 的 一 些 更 高 级 和 比较 少见 的 
特性 (本 章 并 不 想 成 为 PL/pgSQL 的 一 份 完 整 教程 ) 。 

然后 ， 核 心 还 包括 运行 以 Perl 编写 的 存储 过 程 的 代码 。 说 白 了 ， 这 里 的 逻辑 是 相同 
的 。 代 码 将 被 作为 一 个 字符 串 传递 并 且 由 Perl 执行 。PostgreSQL 并 不 会 Perl 语言 一 一 它 仅 
仅 是 将 代码 转交 给 外 部 编程 语言 而 已 。 

也 许 读者 已 经 注意 到 了 Perl 和 TCL 都 有 两 种 形式 ， 可 信 的 〈PL/Perl 和 PL/TCL) 以 
及 不 可 信 的 〈PL/PerIU 和 PL/TCLU)〉 。 可 信 的 和 不 可 信 的 语言 之 间 的 区 别 实际 上 很 重 
要 。 在 PostgreSQL 中 ， 一 种 语言 会 被 直接 载 入 数据 库 连接 中 。 因 此 ， 该 语言 能 够 做 很 多 
很 不 好 的 事情 。 为 了 除去 安全 性 问题 ， 可 信 语 言 的 概念 被 发 明 出 来 。 其 思想 是 可 信 语 言 
被 限制 在 该 语言 非常 核心 的 部 分 中 ， 它 不 能 做 下 面 的 事情 : 

@ 包括 库 。 

@ 打开 网 络 套 接 字 。 

@ ”执行 任何 类 型 的 系统 调用 (打开 文件 等 )。 

Perl 提供 了 感染 模式 ， 它 被 用 来 实现 PostgreSQL 中 的 这 种 特性 。Perl 将 自动 把 自身 
限制 在 可 信和 模式 ， 在 将 要 违背 安全 性 时 报错 。 在 不 可 信和 模式 中 ， 所 有 的 事情 都 可 以 发 
生 ， 因 此 只 有 超级 用 户 被 允许 运行 不 可 信 代 码 。 

如 果 想 要 运行 可 信 的 以 及 不 可 信 的 代码 ， 必 须 激活 两 种 语言 : plperl 和 plperlu (相应 
的 还 有 pltcl 和 pltclu) 。 

Python 当前 只 能 作为 一 种 不 可 信 语 言 使 用 ， 因 此 ， 在 涉及 安全 性 时 管理 员 必 须 非常 
小 心 ， 因 为 运行 在 不 可 信 模 式 的 存储 过 程 可 能 绕 过 PostgreSQL 实施 的 所 有 安全 性 机 制 。 
不 管 怎样 ， 只 要 记 住 一 点 就 好 ，Python 是 作为 数据 库 连 接 的 一 部 分 运行 并 且 绝 不 对 安全 


性 负责 。 
7.2.1 引入 PLpgSQL 
让 我 们 从 最 令 人 期 待 的 话题 开始 ， 笔 者 相信 读者 将 会 热衷 于 多 了 解 一 些 有 关于 它 的 
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内 容 。 
本 节 将 介绍 PL/pgSQL 的 一 些 更 高 级 的 特性 ， 它 们 对 于 编写 正确 且 高 效 的 代码 非常 重 
要 。 注 意 这 并 非 是 针对 新 手 的 编程 或 者 PL/pgSQL 介绍 。 


1， 处 理 引 用 
数据 库 编程 中 最 重要 的 事情 之 一 是 引用 。 如 果 没有 使 用 正确 的 引用 ， 肯 定 会 受到 


SQL 注入 以 及 开放 的 不 可 接受 的 安全 漏洞 困扰 。 
什么 是 SQL 注入 ? 考虑 下 面 的 例子 : 


CREATE FUNCTION broken (text) 
RETURNS void AS 





喇 





$$ 
DECLARE 
VvV_sql text; 
BEGIN 
VvV_sql := "SELECT schemaname 
FROM pg tables 
WHERE tablename = ""'" || $1 1| "5 
RAISE NOTICE 'v sql: %', v sql; 
RETURN; 
END; 


$$ LANGUAGE 'plpgsql'; 

在 这 个 例子 中 ，SQL 代码 被 简单 地 粘贴 在 一 起 ， 根 本 不 担心 安全 性 。 这 里 所 做 的 一 
切 就 是 使 用 “||” 操 作 符 串 接 字 符 串 。 如 果 人 们 运行 正常 的 查询 ， 这 会 工作 得 很 好 : 

SELECT broken('t test'); 

但 是 ， 我 们 必须 时 刻 防备 坏人 。 考 虑 下 面 的 例子 : 

SELECT broken('''; DROP TABLE t test; '); 

用 这 个 参数 运行 该 函数 会 给 我 们 带 来 一 个 吸引 人 的 小 问题 : 


NOTICE: Vv_sql: SELECT schemaname FROM pg_ tables 


WHERE tablename = ''; DROP TABLE t test; " 
CONTEXT: PL/pgSQL function broken(text) line 6 at RAISE 
broken 
(1 row) 


在 只 想 查 找 时 却 删除 了 一 个 表 ， 这 当然 不 是 我 们 想 要 做 的 事情 。 基 于 传递 给 语句 的 
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参数 来 建立 应 用 的 安全 性 绝对 不 可 接受 。 

为 了 避免 SQL 注入 ，PostgreSQL 提供 了 多 种 函数 ， 应 该 一 直 使 用 它们 来 确保 安全 性 
不 受 损伤 : 

test=# SELECT quote literal(E'o''reilly'), 

quote ident (E'o''reilly'); 
quote literal | quote ident 
ES Fe a 
'o''reilly" [1 








(1 row) 


quote literal 函数 转 义 字符 串 的 方式 不 会 再 发 生 不 好 的 事 。 它 在 字符 串 周围 加 上 所 有 的 
引号 ， 转 义 字 符 串 内 有 问题 的 字符 。 因 此 ， 就 不 再 需要 手工 开始 和 结束 字符 串 。 

这 里 展示 的 第 二 个 函数 是 quote ident。 它 可 以 被 用 来 正确 地 引用 对 象 名 称 。 注 意 它 
会 使 用 双 引 号 ， 这 正 是 处 理 表 名 和 类 似 东西 所 需要 的 : 

test=# CREATE TABLE "Some stupid name" ("ID" int) 

CREATE TABLE 

test=# d "Some stupid name" 

Table "public.Some stupid name" 

Column | Type | Modifiers 

A -SE 

ID | integer | 


通常 ，PostgreSQL 中 所 有 的 表 名 都 是 小 写 。 但 是 ， 如 果 使 用 了 双 引 号 ， 对 象 名 称 可 
以 包含 大 写字 母 。 一 般 来 说 ， 这 种 技巧 并 不 是 什么 好 主意 ， 因 为 这 种 情况 下 用 户 不 得 不 
始终 使 用 双 引 号 ， 这 有 点 不 方便 。 

在 引用 的 基本 介绍 之 后 ， 有 必要 看 看 NULL 值 是 如 何 被 处 理 的 : 

test=# SELECT quote literal (NULL); 

quote literal 








(1 row) 


如 果 在 一 个 NULL 值 上 调用 quote_literal 函数 ， 它 将 简单 地 返回 NULL。 这 种 情况 下 
也 没有 必要 关注 引用 。 

PostgreSQL 甚至 提供 了 更 多 函数 来 明确 地 应 对 NULL 值 : 

test=# SELECT quote nullable(123), 


quote nullable (NULL); 
quote nullable | quote nullable 
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不 仅 可 以 引用 字符 串 和 对 象 名 称 ， 还 可 以 使 用 PL/pgSQL 自 带 的 方法 来 格式 化 和 准备 
整个 查询 。 这 里 的 妙 处 是 用 户 可 以 使 用 format 函数 为 语句 增加 参数 。 下 面 是 用 法 : 

CREATE FUNCTION simple format() 

RETURNS text AS 





$5 
DECLARE 
vstring text; 
VvV_result text; 
BEGIN 
V string := format('SELECT schemaname 


MI tablenane 
FROM pg tables 
WHERE %I = $1 
AND %I = $2', 'schemaname', 'tablename'); 
EXECUTE v_string USING ‘public', 't test' INTO v result; 
RAISE NOTICE "result: %', Vv_ result; 
RETURN v_string; 
END; 
$$ LANGUAGE ‘plpgsql'; 
域 的 名 称 被 传递 给 format 函数 。 最 后 ，EXECUTE 语句 的 USING 子 句 把 参数 增加 到 
查询 中 ， 然 后 查询 被 执行 。 再 一 次 ， 这 里 的 好 处 是 不 会 发 生 SQL 注入 。 
下 面 是 执行 后 的 效果 : 
test=# SELECT simple format (); 
NOTICE: result: public .t test 


CONTEXT: PL/pgSQL function simple format() line 12 at RAISE 
simple format 


SELECT schemaname 证 
Wn tablename 

FROM pg tables 二 

WHERE schemaname = $1 二 


AND tablename = $2 


(1 row) 


如 你 所 见 ， 调 试 信息 正确 地 显示 了 包括 方案 的 表 名 并 且 正 确 地 返回 了 查询 语句 。 
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2. 管理 作用 域 


在 大 体 上 处 理 了 引用 和 基本 安全 性 (SQL 注入 ) 之 后 ， 笔 者 想 要 把 读者 的 焦点 转移 
到 另 一 个 重要 的 主题 : 作用 域 。 

正如 笔者 所 知道 的 最 流行 的 编程 语言 一 样 ，PL/pgSQL 依赖 于 上 下 文 环境 使 用 变量 。 变 
量 在 一 个 函数 的 DECLARE 语句 中 定义 。 不 过 ，PL/pgSQL 允许 用 户 嵌 套 DECLARE 语句 : 

CREATE FUNCTION scope test () 


RETURNS int AS 
SS 





DECLARE 
dt = 0 
BEGIN 
RATSE, NOTEGCR "4s 江 王 六 
DECLARE 
下 RE5 
BEGIN 
RAISE NOTICE "ii2: %', i; 
END; 
RETURN i; 
END; 

$$ LANGUAGE ‘'plpgsql'; 

DECLARE 语句 定义 了 一 个 变量 i 并 且 为 它 进 行 了 赋值 ， 然 后 i 被 显示 ， 输 出 当然 将 
会 是 0。 然 后 第 二 个 DECLARE 语句 开始 。 它 包含 i 的 一 个 额外 的 化 身 ， 但 没有 被 赋值 。 
因此 ， 该 值 将 会 是 NULL。 注 意 现在 PostgreSQL 显示 内 层 的 1。 结果 如 下 : 

test=# SELECT scope test(); 

NOTICE: il: 0 

CONTEXT: PL/pgSQL function scope test() line 5 at RAISE 

NOTICE: i2: <NULL> 


CONTEXT: PL/pgSQL function scope test() line 10 at RAISE 
scope test 


(1 row) 
不 出 所 料 ， 调 试 信息 将 显示 0 和 NULL。 


PostgreSQL 允许 用 户 运 用 各 种 各 样 的 技巧 。 不 过 ， 强 烈 推 荐 保持 代码 的 简 
单 和 易 读 。 
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3。， 理解 高 级 错误 处 理 


在 每 种 编程 语言 、 每 个 程序 以 及 每 个 模块 中 ， 错 误 处 理 都 是 一 件 重要 的 事情 。 每 件 
事情 都 偶尔 会 出 错 ， 因 此 正确 和 专业 地 处 理 错误 是 至 关 重 要 的 。 在 PL/pgSQL 中 ， 用 户 可 
以 使 用 EXCEPTION 块 来 处 理 错 误 。 其 思想 是 ， 如 果 BEGIN 块 做 错 了 什么 事情 ， 
EXCEPTION 块 将 注意 到 并 且 正 确 地 处 理 问题 。 就 像 很 多 其 他 语言 (如 Java) 一 样 ， 用 户 
可 以 分 别 对 不 同类 型 的 错误 做 出 反应 并 且 捕 获 它们 。 

在 下 面 的 例子 中 ， 代 码 将 会 出 现 一 个 除 零 问 题 。 我 们 的 目标 就 是 捕捉 到 这 个 错误 并 
且 相 应 地 做 出 反应 : 


CREATE FUNCTION error testl(int, int) 
RETURNS int AS 
































$$ 
BEGIN 
RAISE NOTICE 'debug message: $ / $%$', $1, $2; 
BEGIN 
RETURN $1 / $2; 
EXCEPTION 
WHEN division by zero THEN 
RAISE NOTICE "division by zero detected: $%', 
sqlerrm; 
WHEN others THEN 
RAISE NOTICE "Some other error: $%', 
sqlerrm; 
END; 
RAISE NOTICE 'all errors handled'; 
RETURN 0; 
END; 


$$ LANGUAGE '‘'plpgsql'; 


BEGIN 块 能 够 明确 地 抛 出 错误 。 不 过 ，EXCEPTION 块 会 捕捉 到 我 们 所 要 考虑 的 错 
误 并 且 还 会 注意 可 能 意外 出 现 的 所 有 其 他 问题 。 

技术 上 ， 这 或 多 或 少 与 保存 点 相同 ， 因 此 错误 不 会 导致 整个 事务 完全 失败 。 只 有 导 
致 该 错误 的 块 将 会 遭受 微型 的 回 滚 。 

通过 检查 sqlerrm 变量 ， 用 户 还 可 以 直接 访问 错误 消息 本 身 。 让 我 们 运行 代码 : 

test=# SELECT error test1(9, 0); 


NOTICE: debug message: 9/0 
CONTEXT: PL/pgSQL function error testl (integer,integer) line 3 at RAISE 
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NOTICE: division by zero detected: division by zero 

CONTEXT: PL/pgSQL function error testl (integer,integer) line 9 at RAISE 
NOTICE: all errors handled 

CONTEXT: PL/pgSQL function error testl (integer,integer) line 14 at RAISE 
error testl 


(1 row) 


PostgreSQL 在 EXCEPTION 块 中 捕捉 该 异常 并 且 显 示 消息 。PostgreSQL 已 经 足够 友 
好 地 告诉 我 们 错误 发 生 在 哪 一 行 以 及 出 现 问题 时 怎样 能 更 容易 地 调试 和 修复 代码 。 
在 某 些 情况 下 ， 还 有 必要 抛 出 用 户 自 己 的 异常 。 如 你 所 料 ， 这 很 容易 做 到 : 
RAISE unique violation 
USING MESSAGE = "Duplicate user ID: ' || user id; 


除了 已 经 看 到 的 内 容 之 外 ，PostgreSQL 提供 了 很 多 预定 义 的 错误 代码 和 异常 。 下 面 
的 页 面包 含 了 这 些 错 误 消息 的 完整 列表 : https://www.postgresql.org/docs/9.6/static/errcodes- 
appendix.html。 


4. 使 用 GET DIAGNOSTICS 


读者 中 很 多 曾 用 过 Oracle 的 人 可 能 很 熟悉 GET DIAGNOSTICS 子 句 。GET 
DIAGNOSTICS 子 句 的 思想 是 允许 用 户 看 到 系统 中 在 进行 着 什么 。 虽 然 这 种 语法 对 于 习惯 
了 现代 代码 的 人 来 说 可 能 有 些 奇 怪 ， 它 仍然 是 一 种 可 以 用 来 让 应 用 变 得 更 好 的 有 价值 的 
工具 。 

在 笔者 看 来 ，GET DIAGNOSTICS 子 句 可 用 于 以 下 两 种 主要 任务 : 

@ ”检查 行 计数 。 

@ 取得 上 下 文 信息 并 且 得 到 回 济 。 

检查 行 计数 绝对 是 在 日 常 编程 中 需要 做 的 一 件 事情 。 而 如 果 想 要 调试 应 用 ， 提 取 上 
下 文 信息 将 会 很 有 用 。 

下 面 的 例子 展示 了 如 何在 代码 中 使 用 GET DIAGNOSTICS 子 句 : 

CREATE FUNCTION get diag() 


RETURNS int AS 
SS 








DECLARE 
Ee: TntR 


_sqlstate text; 
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_message text; 
_Context text; 


BEGIN 
EXECUTE "SELECT * FROM generate series(1, 10)'; 
GET DIAGNOSTICS rc = ROW COUNT; 


RAISE. NOTICE: "row count: $%"; res 


SELECT rc / 0; 
EXCEPTION 
WHEN OTHERS THEN 


GET STACKED DIAGNOSTICS 
sqlstate = returned sqlstate, 
message = message text, 
_Ccontext = pg exception context; 
RAISE NOTICE "sqlstate: %, message: $%, 
context: [%]"', 
sqlstate, message, 
replace'( Contexzt, En ” < ")s 
RETURN rc; 
END; 
$$ LANGUAGE ‘plpgsql'; 
定义 那些 变量 之 后 的 第 一 件 事情 是 执行 一 个 SQL 语句 ， 并 且 向 GET DIAGNOSTICS 
子 句 要 求 行 计数 ， 接 着 行 计数 会 被 显示 在 调试 信息 中 。 
然后 该 函数 强制 PL/pgSQL 报错 。 一旦 报错， 就 可 以 使 用 GET DIAGNOSTICS 子 句 
从 服务 器 提取 信息 显示 。 
下 面 是 执行 的 效果 : 
test=# SELECT get _ diag() 
NOTICE: row count: 10 
CONTEXT: PL/pgSQL function get diag() line 12 at RAISE 
NOTICE: sqlstate: 22012, 
message: division by zero, 
context: [SQL statement "SELECT rc / 0" 
<- PL/pgSQL function get diag() line 14 at 
SQL statement] 
CONTEXT: PL/pgSQL function get diag() line 22 at RAISE 
get diag 
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10 
(1 row) 


如 你 所 见 ，GET DIAGNOSTICS 子 句 对 系统 中 正在 进行 什么 给 出 了 非常 详细 的 信息 。 
5， 在 块 中 使 用 游标 取 数 据 


如 果 用 户 执行 SQL， 数据 库 将 计算 结果 并 且 把 结果 发 给 用 户 的 应 用 。 

一 旦 整个 结果 集 被 发 送 到 客户 端 ， 应 用 就 可 以 继续 做 自己 的 工作 。 但 问题 是 ， 如果 
结果 集 大 到 无 法 再 放 入 内 存 中 ， 会 发 生 什 么 ? 如 果 数 据 库 返回 100 亿 行 会 怎样 ? 客户 端 
应 用 通常 不 能 一 次 处 理 这 么 多 的 数据 并 且 它 也 不 应 该 这 样 做 。 这 类 问题 的 解决 方案 是 游 
标 。 游 标的 思想 是 只 在 需要 数据 时 (调用 FETCH 时 ) 才 产 生 数 据 。 因 此 ， 在 数据 实际 被 
数据 库 生 成 时 应 用 可 能 已 经 开始 消耗 数据 。 此 外 ， 执 行 操作 所 需 的 内 存 也 低 很 多 。 

对 于 PL/pgSQL， 游 标 也 扮演 了 重要 的 角色 。 只 要 对 一 个 结果 集 进行 循环 ，PostgreSQL 
在 内 部 就 将 自动 使 用 一 个 游标 。 其 优点 在 于 应 用 的 内 存 消耗 将 被 极 大 地 降低 并 且 很 少 会 出 
现 由 于 处 理 大 量 数 据 导致 的 内 存 不 足 现象 。 有 多 种 方法 使 用 游标 ， 下 面 是 最 简单 的 一 种 : 

CREATE FUNCTION c (int) 


RETURNS setof text AS 
$5 























DECLARE 
V rec record; 
BEGIN 
FOR Vv rec IN SELECT tablename FROM pg tables LIMIT $1 
LOOP 
RETURN NEXT Vv_rec.tablename; 
END LOOP; 


RETURN; 
END; 

$$ LANGUAGE '‘'plpgsql'; 

这 段 代码 有 两 个 有 意思 的 地 方 。 首 先 ， 它 是 一 个 集合 返回 函数 (SRF〉。 它 产生 一 整 
列 而 不 只 是 单个 行 。 实 现 这 一 点 的 方式 是 使 用 setof 变量 而 不 只 是 数据 类 型 。RETURN 
NEXT 子 句 将 构建 结果 集 ， 直 到 我 们 到 达 结 尾 处 。RETURN 子 句 会 告诉 PostgreSQL 我 们 
想 要 离开 函数 并 且 结 果 已 经 形成 。 

第 二 个 重要 的 问题 是 在 游标 上 循环 将 自动 创建 一 个 内 部 游标 。 换 句 话说 ， 没 有 必要 
担心 可 能 会 出 现 内 存 不 足 。PostgreSQL 将 以 一 种 尽 可 能 快 产生 前 10% 数 据 (由 cursor_ 
tuple_fraction 变量 定义 ) 的 方式 来 优化 查询 。 
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下 面 是 该 查询 将 返回 的 结果 : 


test=# SELECT * FROM c(3); 











七 test 

pg statistic 

pg type 

(3 rows) 

在 这 个 例子 中 ， 结 果 将 仅仅 是 一 个 随机 表 组 成 的 列表 。 如 果 在 读者 的 环境 中 产生 的 
结果 不 同 ， 那 也 是 意料 之 中 的 。 

在 笔者 看 来 ， 我 们 已 经 看 到 的 是 在 PL/pgSQL 中 使 用 隐 式 游标 的 最 频繁 和 最 常见 的 方 
式 。 下 面 的 例子 展示 了 一 种 更 古老 的 机 制 ， 很 多 以 前 使 用 Oracle 的 人 可 能 都 知道 : 

CREATE FUNCTION d (int) 


RETURNS setof text AS 
$$ 








DECLARE 
V cur refcursor; 
V data text; 


BEGIN 
OPEN V_cur FOR SELECT tablename FROM pg tables LIMIT $1; 


WHILE true 
LOOP 
FETCH V cur INTO V data; 
IF FOUND THEN 
RETURN NEXT V data; 
ELSE 
RETURN; 
END IF; 
END LOOP; 
END; 
$$ LANGUAGE ‘plpgsql'; 


在 这 个 例子 中 ， 游 标 被 显 式 地 声明 和 打开 。 在 内 部 ， 循 环 数据 接着 被 显 式 取得 并 且 
返回 给 调用 者 。 基 本 上 ， 该 查询 做 的 是 和 之 前 完全 相同 的 事情 一 一 这 只 是 开发 者 实际 更 
喜欢 哪 种 语法 的 问题 。 

读者 们 是 否 仍 然 觉得 对 游标 了 解 得 还 不 够 多 ? 确实 有 ， 下 面 是 第 三 种 做 同样 事情 的 
方法 : 
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CREATE FUNCTION e (int) 
RETURNS setof text AS 


$$ 
DECLARE 
V cur CURSOR (paraml]l int) FOR 
SELECT tablename FROM pg tables LIMIT paraml; 
V data text; 
BEGIN 
OPEN v cur ($1); 
WHILE true 
LOOP 
FETCH V cur INTO v data; 
IF FOUND THEN 
RETURN NEXT V data; 
ELSE 
RETURN; 
END IF; 
END LOOP; 
END; 


$$ LANGUAGE 'plpgsql'; 


在 这 种 情况 下 ， 游 标 得 到 一 个 整数 参数 ， 它 直接 来 自 于 函数 调用 ($1) 。 
有 时 ， 存 储 过 程 并 未 用 尽 一 个 游标 ， 而 是 将 它 返回 以 便 后 续 使 用 。 在 这 种 情况 下 ， 
可 以 使 用 refeursor 作为 返回 值 : 


CREATE OR REPLACE FUNCTION cursor test(c refcursor) 
RETURNS refcursor AS $$ 

BEGIN 

OPEN c FOR 

SELECT * FROM generate series(1, 10) AS id; 

RETURN cc; 

END; 

$$ LANGUAGE plpgsql; 


这 里 的 逻辑 很 简单 ， 游 标的 名 字 被 传递 给 函数 ， 然 后 该 游标 被 打开 并 且 返 回 。 这 里 
的 好 处 是 游标 背后 的 查询 可 以 被 即时 创建 并 且 被 动态 编译 。 
应 用 可 以 就 像 在 任何 其 他 应 用 中 那样 从 游标 中 取 数 据 。 下 面 是 用 法 ， 注 意 只 有 使 用 
了 一 个 事务 块 时 才能 如 此 : 


test=# BEGIN; 
BEGIN 
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test=# SELECT cursor test('mytest'); 
cursor test 


mytest 
(1 row) 


test=# FETCH NEXT FROM mytest; 
id 


于 
(1 row) 


test=# FETCH NEXT FROM mytest; 
id 


次 

(1 row) 

实际 上 ， 在 本 节 中 学 到 的 是 游标 会 根据 消耗 量 来 产生 数据 ， 对 于 大 部 分 应 用 来 说 也 
确实 是 这 样 。 但 是 ， 笔 者 在 这 个 例子 中 加 入 了 一 个 小 圈套 ， 只 要 使 用 SRF， 整 个 结果 就 
不 得 不 被 物化 。 它 不 会 被 即时 创建 ， 而 是 一 次 性 创建 。 原 因 在 于 ，SQL 必须 能 够 重新 扫 
描 一 个 关系 ， 在 普通 表 的 情况 下 可 能 很 容易 做 到 。 但 是 ， 函 数 的 情况 就 不 同 了 。 因 此 ， 
SRF 总 是 会 被 计算 并 且 物 化 ， 这 就 让 这 个 例子 中 的 游标 变 得 完全 无 用 。 换 名 话说， 在 编 
写 函 数 时 要 小 心 一 一 在 某 些 情况 下 ， 和 危险 就 隐藏 在 精巧 的 细节 中 。 


6.， 利用 组 合 类 型 


在 大 部 分 其 他 数据 库 系统 中 ， 存 储 过 程 只 用 于 简单 数据 类 型 ， 例 如 integer、 
numeric、varchar 等 。 不 过 ，PostgreSQL 完全 不 同 ， 用 户 基本 上 可 以 使 用 所 有 可 用 的 数据 
类 型 ， 这 包括 基本 类 型 以 及 组 合 类 型 和 自 定义 类 型 。 就 所 涉及 的 数据 类 型 而 言 ， 可 以 说 
根本 没有 限制 。 为 了 发 挥 出 PostgreSQL 的 全 部 实力 ， 组 合 类 型 非常 重要 并 且 经 常会 被 互 
联网 上 的 各 种 扩展 使 用 。 

下 面 的 例子 展示 了 组 合 类 型 如 何 被 传递 给 函数 以 及 它 在 内 部 被 如 何 使 用 。 最 后 ， 组 
合 类 型 将 被 返 


CREATE TYPE my_cool _ type AS (s text, t text); 








回 





CREATE FUNCTION f(my cool type) 
RETURNS my cool type AS 
$$ 
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DECLARE 
V row my cool type; 
BEGIN 
RAISE NOTICE 'schema: ($) / table: ($)', $1.s, $1.t; 
SELECT schemaname, tablename INTO V row 
FROM pg tables 
WHERE tablename = trim($1.t) 
AND schemaname = trim($1.s) 
DIMIT TS 
RETURN vV_ row; 
END; 

$$ LANGUAGE ‘'plpgsql'; 

这 里 的 主要 问题 是 用 户 可 以 简单 地 使 用 $1.field_name 来 访问 组 合 类 型 。 返 回 类 型 也 
不 难 ， 用 户 只 需要 即时 组 装 组 合 类 型 变量 并 且 像 其 他 数据 类 型 那样 返回 即 可 。 用 户 甚至 
可 以 轻易 地 使 用 数组 或 者 更 加 复杂 的 结构 。 

下 面 的 示例 展示 了 PostgreSQL 将 返回 的 结果 : 

test=# SELECT (f).s, (f).t 

FROM ff (" ("public, “Et test"): :my cool tybe)s 


NOTICE: schema: (public) / table: (七 test) 
CONTEXT: PL/pgSQL function fl(my cool type) line 5 at RAISE 














3 | 所 
二 二 
public | t test 

(1 row) 


7. 用 PL/pgSQL 编写 触发 器 


如 果 用 户 想 要 对 数据 库 中 发 生 的 特定 事件 做 出 反应 ， 服 务 器 端 代码 特别 受 欢迎 。 触 
发 器 允许 用 户 在 表 上 发 生 INSERT、UPDATE、DELETE 或 者 TRUNCATE 子 句 时 调用 一 
个 函数 。 然 后 被 触发 器 调用 的 函数 修改 表 中 发 生 改变 的 数据 或 者 简单 地 执行 某 个 需要 的 
操作 。 

在 PostgreSQL 中 ， 触 发 器 这 些 年 来 已 经 变 得 更 加 强大 并 且 提 供 了 丰富 的 特性 集合 : 

test=# h CREATE TRIGGER 


Command: CREATE TRIGGER 
Description: define a new trigger 





Syntax: 
CREATE [ CONSTRAINT ] TRIGGER name { BEFORE | AFTER | INSTEAD OF } 
{ event [ OR ... 1 
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ON table name 
[ FROM referenced table name ] 
[ NOT DEFERRABLE | [ DEFERRABLE ] 
[ INITIALLY IMMEDIATE | INITIALLY DEFERRED ] ] 
[ FOR [ EACH ] { ROW | STATEMENT } ] 
[ WHEN ( condition ) ] 
EXECUTE PROCEDURE function name ( arguments ) 


这 里 ， 事 件 可 以 是 下 列 之 一 : 


INSERT 
UPDATE [OF column name [, =»: 1] 
DELETE 
TRUNCATE 


第 一 个 要 注意 的 地 方 是 触发 器 总 是 为 一 个 表 或 者 ”一 个 视图 被 触发 ， 并 且 调 用 一 个 函 
数 。 触 发 器 有 一 个 名 称 并 且 可 以 在 事件 之 前 或 者 之 后 发 生 。PostgreSQL 的 妙 处 在 于 用 户 
可 以 根据 需要 在 单个 表 上 有 任意 多 个 触发 器 。 虽 然 这 对 专家 级 的 PostgreSQL 用 户 来 说 没 
什么 可 惊讶 的 ， 笔 者 还 是 要 指出 世界 上 仍 在 使 用 的 很 多 昂贵 的 商业 数据 库 引擎 却 做 不 到 
如 果 在 同一 个 表 上 有 多 于 一 个 触发 器 ， 则 会 使 用 很 多 年 前 在 PostgreSQL 7.3 中 引入 的 
规则 :触发 器 按照 字母 顺序 被 引发 。 首 先 ， 所 有 那些 前 触发 器 以 字母 顺序 发 生 ， 然 后 
PostgreSQL 执行 引发 触发 器 的 行 操作 并 且 继 续 按 字母 顺序 执行 后 触发 器 。 换 句 话 说 ， 触 
发 器 的 执行 顺序 是 绝对 确定 的 ， 并 且 触 发 器 的 数量 基本 上 是 无 限 的 。 
触发 器 可 以 在 实际 修改 发 生 之 前 或 者 之 后 修改 数据 。 一 般 来 说 ， 这 是 一 种 验证 数据 
且 在 某 些 自 定义 限制 被 违背 时 报错 的 好 办 法 。 下 面 的 例子 展示 了 一 个 由 INSERT 子 句 
引发 的 触发 器 ， 它 会 更 改 加 入 表 的 数据 : 


CREATE TABLE 七 sensor ( 


























id serial, 
ts timestamp, 
temperature numeric 


); 
我 们 的 表 只 存储 若干 值 ， 现 在 的 目标 是 一 插入 行 就 调用 一 个 函数 : 


CREATE OR REPLACE FUNCTION trig func() 
RETURNS trigger AS 
SS 





9 原文 是 “a table of a view”， 应 为 笔 误 。 


“8S= 


BEGIN 


IF NEW.temperature < -273 
THEN 
NEW.temperature := 0; 
END IF; 
RETURN NEW; 
END; 


$$ LANGUAGE ‘plpgsql'; 


如 前 所 述 ， 触 发 器 将 总 是 调用 一 个 函数 ， 这 人 允许 用 户 精 细 地 抽象 代码 。 这 里 的 重点 
是 触发 器 函数 必须 返回 trigger。 要 访问 将 要 插入 的 行 ， 用 户 可 以 访问 NEW 变量 。 
6 INSERT 和 UPDATE 触发 器 总 是 提供 一 个 NEW 变量 。UPDAIE 和 

DELETE 总 是 提供 一 个 名 为 OLD 的 变量 。 那 些 变量 包含 将 要 修改 的 行 。 

在 笔者 的 例子 中 ， 代 码 检查 温度 是 否 太 低 。 如 果 温 度 太 低 ， 值 就 不 行 ， 它 会 被 动态 
调整 。 为 了 确保 能 使 用 被 修改 的 行 ， NEW 被 返回 。 如 果 有 第 二 个 触发 器 在 这 一 个 之 后 被 
调用 ， 下 一 个 函数 调用 将 看 到 被 修改 的 行 。 

在 下 一 步 ， 创 建 这 个 触发 器 


CREATE TRIGGER sensor trig 
BEFORE INSERT ON t sensor 


FOR EACH ROW 
EXECUTE PROCEDURE trig func(); 


下 面 是 该 触发 器 的 效果 : 
test=# INSERT INTO t_ sensor (ts, temperature) 
VALUES ('2017-05-04 14:43', -300) 


RETURNING *; 

id | Ee | temperature 
ee a 
1 | 2017=05=04" 14:43=:000] 0 

(1 row) 
INSERT 0 1 


如 你 所 见 ， 值 已 经 被 正确 地 调整 ， 表 中 该 温度 显示 为 0。 
如 果 用 户 在 使 用 触发 器 ， 用 户 应 该 意识 到 一 点 ， 触 发 器 对 其 自身 有 很 深 的 了 解 。 


能 访问 若干 变量 ， 这 些 变量 允许 用 户 编写 更 精致 的 代码 并 且 实 现 更 好 的 抽象 。 
让 我 们 先 删除 这 个 触发 器 : 
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test=# DROP TRIGGER sensor trig ON t sensor; 
DROP TRIGGER 


然后 增加 一 个 新 函数 


CREATE OR REPLACE FUNCTION trig demo() 

RETURNS trigger AS 

$$ 

BEGIN 
RAISE NOTICE '‘'TG NAME: $%', TG NAME; 
RAISE NOTICE ‘TG RELNAME: $', TG RELNAME; 
RAISE NOTICE 'TG TABLE SCHEMA: %', 
TG_TABLE SCHEMA; 

RAISE NOTICE 'TG TABLE NAME: %', TG TABLE NAME; 
RAISE NOTICE ‘TG WHEN: %', TG WHEN; 
RAISE NOTICE "TG LEVEL: $%', TG LEVEL; 
RAISE NOTICE "TG OP: $%', TG OP; 
RAISE NOTICE "TG NARGS: %', TG NARGS; 
-- RAISE NOTICE ‘TG ARGV: $%', TG NAME; 


RETURN NEW; 
END; 
$$ LANGUAGE '‘'plpgsql'; 


这 里 用 到 的 所 有 变量 都 是 预定 义 好 的 ， 并 且 默 认 就 可 用 。 我 们 的 代码 所 做 的 只 是 显 
示 它 们 以 便 能 看 到 其 内 容 : 
CREATE TRIGGER demo trigger 


BEFORE INSERT ON t sensor 
FOR EACH ROW EXECUTE PROCEDURE trig demo(); 





test=# INSERT INTO t sensor (ts, temperature) 
VALUES ('2017-05-04 14:43', -300) RETURNING *; 
NOTICE: TG NAME: demo trigger 
NOTICE: TG RELNAME: t_ sensor 
NOTICE: TG TABLE SCHEMA: public 
NOTICE: TG TABLE NAME: t sensor 
NOTICE: TG WHEN: BEFORE 
NOTICE: TG LEVEL: ROW 
NOTICE: TG OP: INSERT 
NOTICE: TG NARGS: 0 
id | Es | temperature 
A 相 计生 站 下 全 二 大 全 全 本 


第 7 章 ”编写 存储 过 程 “187。 
2 1 2017-=-05-04 14:43:00 | -300 
(1 row) 


INSERT 0 1 


这 里 读者 可 以 看 到 ， 触 发 器 知道 它 的 名 字 ， 是 为 哪个 表 被 触发 等 信息 。 如 果 用 户 想 
对 多 个 表 应 用 类 似 的 动作 ， 那 些 变量 能 帮助 用 户 通过 仅 编 写 一 个 函数 来 避免 重复 代码 ， 
然后 这 个 函数 可 以 被 用 于 所 有 感 兴趣 的 表 。 


7.2.2 引入 PL/Perl 





关于 PL/pgSQL 还 有 更 多 可 说 的 。 但 是 由 于 笔者 只 有 有 限 的 页 数 来 涵盖 这 一 主题 ， 现 
在 是 时 候 进 入 下 一 种 过 程 语言 了 。PL/Perl 已 经 被 很 多 人 接受 作为 处 理 字 符 串 的 理想 语 
言 。 读 者 可 能 知道 ，Perl 以 其 字符 串 操纵 能 力 而 闻名 ， 因 此 在 这 么 多 年 后 仍然 相当 流行 。 

要 启用 PL/Perl， 用 户 有 两 种 选择 ; 


[postgres@linuxpc ~]$ createlang plper]l test 
[postgres@linuxpc ~]$ createlang plperlu test 


用 户 可 以 部 署 可 信 的 和 不 可 信 的 Perl。 如 果 两 者 都 想 要 ， 用 户 必须 两 种 语言 都 启用 。 
为 了 向 读者 展示 PL/Perl 如 何 工作 ， 笔 者 已 经 实现 了 一 个 函数 ， 它 简单 地 解析 一 个 
email 地 址 并 且 返 回 真 或 假 。 下 面 是 该 函数 的 定义 : 

test=# CREATE OR REPLACE FUNCTION verify email (text) 
RETURNS boolean AS 
$$ 

if (st00 == /a=z0=9. J]+e la=z0=9=]J+9/) 

{ 

return i traes 

} 

return false; 
$$ LANGUAGE 'plperl'; 
CREATE FUNCTION 


一 个 文本 参数 被 传递 给 该 函数 。 在 函数 中 ， 所 有 的 输入 参数 可 以 通过 使 用 $_ 访 问 。 
在 这 个 例子 中 ， 先 执行 了 正则 表达 式 ， 然 后 函数 返回 。 
可 以 像 用 任何 其 他 语言 编写 的 任何 其 他 过 程 一 样 调用 这 个 函数 : 


test=# SELECT verify email('hs@cybertec.at'); 
verify email 





"188。 由 浅 入 深 PostgreSQL 


人 


(1 row) 


test=# SELECT verify email('totally wrong'); 
verify email 


(1 row) 


如 果 处 于 一 个 可 信函 数 内 部 ， 记 住 不 能 载 入 包 之 类 的 东西 。 例 如 ， 如 果 想 用 w 命令 
寻找 单词 ，Perl 将 在 内 部 载 入 utf8.pm， 这 当然 是 不 被 允许 的 。 


1， 将 PL/Perl 用 于 数据 类 型 抽象 
正如 本 章 中 所 述 ，PostgreSQL 中 的 函数 相当 通用 并 且 能 在 很 多 不 同 的 上 下 文中 使 
如 果 用 户 想 用 函数 来 提升 数据 质量 ， 可 以 使 用 CREATE DOMAIN 子 句 : 


test=# h CREATE DOMAIN 
Command: CREATE DOMAIN 
Description: define a new domain 

















型 


Syntax: 

CREATE DOMAIN name [ AS ] data type 
[ COLLATE collation ] 
[ DEFAULT expression ] 
eonstraine edd 


where constraint is: 


[ CONSTRAINT constraint name ] 

{ NOT NULL | NULL | CHECK (expression) } 

在 这 个 例子 中 ，PL/Perl 函数 将 用 来 创建 一 个 名 为 email 的 域 ， 随 后 它 可 以 被 用 作 一 
种 数据 类 型 。 

下 面 的 列表 展示 了 如 何 创 建 域 : 

test=# CREATE DOMAIN email AS text 

CHECK (verify email (VALUE) = true); 
CREATE DOMAIN 
如 前 所 述 ， 域 函数 就 像 一 种 普通 数据 类 型 : 


test=# CREATE TABLE t email (id serial, data email); 
CREATE TABLE 
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如 下 例 所 示 ， 这 个 Perl 函数 确保 不 会 有 违背 检查 的 东西 被 成 功 地 插入 数据 库 中 : 


test=# INSERT INTO t email (data) 
VALUES ('somewhere@example.com’'); 
INSERT 0 1 
test=# INSERT INTO t email (data) 
VALUES ('somewhere wrong example.com'); 
ERROR: value for domain email violates check 
constraint "email check" 


Perl 可 能 是 一 种 做 字符 串 处 理 的 好 选择 ， 但 是 是 否 直接 在 数据 库 中 用 这 种 代码 实现 ， 
终究 还 是 由 用 户 决定 。 


2.， 在 PL/Perl 和 PL/PerlU 之 间 做 决定 


到 目前 为 止 ， 这 段 Perl 代码 还 没有 打开 任何 安全 性 相关 的 问题 ， 因 为 笔者 所 用 的 都 
是 正则 表达 式 。 现 在 的 问题 是 ， 如 果 有 人 尝试 在 Perl 函数 内 做 些 不 好 的 事情 会 怎样 ? 如 
前 所 述 ，PL/Perl 将 简单 地 报错 : 

test=# CREATE OR REPLACE FUNCTION test security() 


RETURNS boolean AS 
$5 

















use strict; 
my $fp = open("/etc/password", "r"); 


return false; 
$$ LANGUAGE 'plperl'; 
ERROR: "open' trapped by operation mask at line 3. 
CONTEXT: compilation of PL/Perl function "test security" 


PL/Perl 将 在 尝试 创建 该 函数 时 立即 抱怨 ， 一 个 错误 将 马上 被 显示 出 来 。 
如 果 用 户 真 的 想 运行 用 Perl 写 的 不 可 信 代 码 ， 必 须 使 用 PL/PerlU: 


test=# CREATE OR REPLACE FUNCTION first line() 
RETURNS text AS 
$$ 
open (my $fh, '<:encoding (UTF-8)', "/etc/passwd") 
or elog (NOTICE, "Could not open file '$filename' $!"); 
my $row = <$fh>; 
close ($fh); 


return $row; 
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$$ LANGUAGE ‘plperlu'; 
CREATE FUNCTION 


基本 上 ， 这 个 过 程 和 
所 有 的 事情 。 二 者 唯一 的 区 别 是 该 函数 被 标记 为 plperlu。 
结果 并 不 令 人 惊讶 : 


test=# SELECT first line(); 
first line 


前 一 个 是 完全 相同 的 ， 会 返回 一 个 字符 串 。 但 是 ， 它 被 允许 做 








root:x:0:0:root:/root:/bin/basht+ 
(1 row) 


3. 使 用 SPI 接口 

有 时 ， 用 户 的 Perl 过 程 不 得 不 做 数据 库 工 作 。 记 住 该 函数 是 数据 库 连 接 的 一 部 分 。 
因此 ， 再 去 创建 一 个 数据 库 连 接 没有 意义 。 为 了 与 数据 库 对 话 ，PostgreSQL 服务 器 基础 
设施 提供 了 SPI 接口 ， 它 是 一 个 与 数据 库 内 部 对 话 的 C 接口 。 所 有 帮助 用 户 运行 服务 器 
端 代码 的 过 程 语言 都 使 用 这 个 接口 所 披露 的 功能 。PL/Perl 同样 如 此 ， 在 本 节 中 ， 读 者 将 
学 到 如 何 使 用 Perl 包装 这 种 SPI 接 口 。 

用 户 可 能 想 做 的 最 重要 的 事情 是 运行 SQL 并 且 检 索取 得 的 行 数 。spi_exec_query 函数 
就 负责 这 种 工作 。 第 二 个 参数 是 实际 想 要 检索 的 行 数 。 为 了 保持 简单 ， 笔 者 决定 检索 所 
有 的 行 : 

test=# CREATE OR REPLACE FUNCTION spi sample (int) 


RETURNS void AS 
$$ 

















my SrV = spi exec query(" 
SELECT * 
FROM generate series(1, $_ [0])", $ [0]); 


elog (NOTICE, "rows fetched: " . S$rv->{processed}); 


elog (NOTICE, "status: " . $rv->{status}); 


return; 
$$ LANGUAGE ‘plperl'; 
SPI 会 漂亮 地 执行 这 个 查询 并 且 显示 行 数 。 这 里 的 重点 是 所 有 的 存储 过 程 语言 都 提供 
一 种 方法 来 发 送 日 志 消 息 。 在 PL/Perl 中 ， 这 个 函数 叫 作 elog， 并 且 接 受 两 个 参数 。 第 一 
个 参数 定义 消息 的 重要 度 (INFO、NOTICE、WARNING、ERROR 等 ) ， 而 第 二 个 参数 
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包含 实际 的 消息 。 
下 面 的 消息 显示 查询 返回 的 内 容 : 
test=# SELECT spi sample(9); 
NOTICE: rows fetched: 9 


NOTICE: status: SPI OK SELECT 
spi_sample 





(1 row) 


4. 将 SPI 用 于 集合 返回 函数 


在 很 多 情况 下 ， 用 户 不 只 想 执行 某 个 SQL 就 完了 。 在 大 部 分 情况 下 ， 一 个 过 程 将 在 
结果 上 循环 并 且 用 结果 做 一 些 事情 。 下 面 的 例子 将 展示 用 户 如 何在 查询 的 输出 上 循环 。 
此 外 ， 笔 者 决定 对 这 个 例子 做 一 点 补充 并 且 让 该 函数 返回 一 种 组 合 类 型 。 在 Perl 中 使 用 
组 合 类 型 很 容易 ， 因 为 用 户 可 以 简单 地 把 数据 填 入 到 一 个 哈 希 表 并 且 返 回 。return_next 函 
数 将 会 逐步 构建 起 结果 集 ， 直 到 函数 被 一 个 返回 语句 终止。 

这 个 列表 中 的 例子 产生 一 个 包含 随机 值 的 表 : 


CREATE TYPE random type AS (a float8, b float8); 


CREATE OR REPLACE FUNCTION spi srf perl (int) 
RETURNS setof random type AS 
$8 
my SrV = spi query("SELECT random() AS a, random() AS b 
FROM generate series(1, $ [0])"); 
while (defined (my $row = spi fetchrow($rv))) 
{ 
elog (NOTICE, "data: " . $row->{a} 
WM wh 
return next({ 
a col => $row->{a}, 
bcol => $row->{b} 
]}) 7 
| 
return; 
$$ LANGUAGE 'plperl'; 
CREATE FUNCTION 
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首先 ，spi_query 函数 被 执行 并 且 使 用 spi_fetchrow 函数 开始 一 个 循环 。 在 循环 内 ， 组 
合 类 型 将 被 组 装 并 且 被 填 入 结果 集中 。 
不 出 所 料 ， 该 函数 将 返回 一 组 随机 值 : 


test=# SELECT * FROM spi srf perl(3); 

NOTICE: data: 0.154673356097192 / 0.278830723837018 
CONTEXT: PL/Perl function "spi srf perl" 

NOTICE: data: 0.615888888947666 / 0.632620786316693 
CONTEXT: PL/Perl function "spi srf perl" 

NOTICE: data: 0.910436692181975 / 0.753427186980844 
CONTEXT: PL/Perl function "spi srf perl" 


0.154673356097192 
0.615888888947666 
0.910436692181975 


a col 1 b col 


0.278830723837018 
0.632620786316693 
0.753427186980844 


CE ee 
1 
1 
1 


(3 rows) 
记 住 ， 集 合 返 回 函 数 必须 被 实现 ， 这 样 整个 结果 集 将 被 存储 在 内 存 中 。 
5， 在 PL/Perl 中 的 转 义 以 及 支持 函数 


到 目前 为 止 ， 我 们 只 使 用 了 整数 ， 因 此 SQL 注入 或 特殊 表 名 不 会 是 问题 。 如 果 要 面 
对 这 类 问题 ， 有 下 列 函 数 可 用 。 


quote_literal: 返回 一 个 按 字符 串 字面 值 引用 的 字符 串 。 

quote_nullable: 对 一 个 字符 串 加 引用 。 

quote ident: 对 SQL 标识 符 〈 对 象 名 等 ) 加 引用 。 

decode bytea: 解码 一 个 PostgreSQL 字 节 数组 域 。 

encode bytea: 编码 数据 并 且 将 其 转变 成 一 个 字 节 数组 。 

encode literal array: 编码 一 个 字面 值 数组 。 

encode_typed literal: 把 一 个 Perl 变量 转换 成 作为 第 二 个 参数 传 入 的 数据 类 型 的 
值 ， 并 且 返 回 该 值 的 字符 串 表 示 。 

encode array_constructor: 把 被 引用 数组 的 内 容 转 变 成 数组 构造 器 格式 中 的 字 
符 串 。 

looks_like number: 如 果 一 个 字符 串 看 起 来 像 一 个 数字 ， 则 返回 真 。 
is_array_ref: 如 果 某 个 东西 是 一 个 数组 引用 ， 则 返回 真 。 








这 些 函 数 总 是 可 用 ， 并 且 可 以 被 直接 调用 而 不 必 包 括 任何 库 。 
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6。 在 函数 调用 之 间 共 享 数据 

有 时 有 必要 在 多 次 调用 之 间 共 享 数据 ， 这 种 基础 设施 也 有 方法 来 实际 做 到 这 一 点 。 
在 Perl 中 ， 一 个 哈 希 表 被 用 来 存储 任何 需要 的 数据 : 

CREATE FUNCTION perl shared (text) 


RETURNS int AS 
$5 





证 (!defined $ SHARED{$ [0]}) 
{ 
$ SHARED{$ [0]} = 0; 


$_SHARED{S$ [0]}++; 
} 


return $ SHARED{$ [0]}; 
$$ LANGUAGE 'plperl'; 
- 旦 我 们 发 现 传递 给 函数 的 键 不 存在 ，$_SHARED 变量 就 将 被 初始 化 为 0。 对 于 每 
-次 其 他 调用 ， 计 数 器 会 被 加 1， 最 后 给 我 们 下 面 的 输出 : 
test=# SELECT perl shared('some key') FROM generate series(1, 3); 
perl shared 


(3 rows) 


对 更 复杂 语句 的 情况 ， 开 发 者 通常 不 知道 函数 将 被 以 何 种 顺序 调用 ， 因 此 要 牢记 在 
大 部 分 情况 下 不 能 依赖 于 执行 顺序 。 


7.。 用 Perl 编写 触发 器 


每 一 种 随 PostereSQL 核心 发 行 的 存储 过 程 语 言 都 允许 用 户 用 其 编写 存储 过 程 ， 这 同样 
也 适用 于 Perl。 由 于 篇 幅 限制 ， 笔 者 决定 不 包括 用 Perl 编写 的 触发 器 例子 ， 而 是 将 读者 指 
引 到 官方 的 PostgreSQL 文档 : https://www.postgresql.org/docs/9.6/static/plperl-triggers.html。 
基本 上 ， 用 Perl 编写 触发 器 和 用 PL/pgSQL 没什么 区 别 。 所 有 预定 义 的 变量 也 同样 可 
用 ， 至 于 返回 值 ， 规 则 适用 于 每 一 种 存储 过 程 语言 。 
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7.2.3 引入 PUPython 


如 果 用 户 恰好 不 是 一 个 Perl 专家 ，PL/Python 可 能 会 更 合适 。 很 久 以 前 ，Python 就 已 
经 成 为 PostgreSQL 基础 设施 的 一 部 分 ， 因 此 它 是 一 种 可 靠 的 、 久 经 考验 的 实现 。 

在 谈 到 PL/Python 时 ， 有 一 件 事 必须 记 住 ，PL/Python 只 能 用 作 一 种 不 可 信 语 言 。 从 
安全 性 的 角度 而 言 ， 有 必要 始终 牢记 这 一 点 。 

要 启用 PL/Python， 用 户 可 以 从 其 命令 行 运行 下 面 的 命令 。test 是 想 要 与 PL/Python 一 
起 使 用 的 数据 库 名 : 


createlang plpythonu test 





一 旦 该 语言 被 启用 ， 就 已 经 可 以 编写 代码 了 。 
然 ， 用 户 可 以 选择 使 用 CREATE LANGUAGE 子 句 。 还 要 记 住 ， 为 了 使 用 服务 器 
， 需 要 包含 那些 语言 的 PostgreSQL 包 (postgresql-plpython-9.6 等 ) 。 


1， 编写 简 单 的 PL/Python 代码 





汪 
二 
号 


端 语 上 


在 本 节 中 ， 读 者 将 学 到 编写 简单 的 Python 过 程 。 这 里 讨论 的 例子 非常 简单 ， 如 果 用 
户 正在 奥地利 通过 汽车 拜访 客户 ， 用 户 可 以 每 公里 扣除 42 欧 分 作为 开支 来 降低 用 户 的 所 
得 税 。 所 以 该 函数 要 做 的 事情 是 得 到 公里 数 并 且 返 回 可 以 从 税金 账单 中 扣除 的 钱 数 。 代 
码 如 下 : 





CREATE OR REPLACE FUNCTION calculate deduction (km float) 
RETURNS numeric AS 
$$ 

if km <= 0: 


elog (ERROR, ‘invalid number of kilometers') 
else: 


return km * 0.42 
$$ LANGUAGE 'plpythonu'; 


该 函数 确保 只 接受 正 值 。 最 后 ， 结 果 被 计算 出 来 并 且 返 回 。 如 你 所 见 ，Python 函数 
被 传递 给 PostgreSQL 的 方式 实际 上 与 Perl 或 PL/pgSQL 没什么 不 同 。 
2. 使 用 SPI 接口 


和 所 有 过 程 语言 一 样 ，PL/Python 也 可 以 访问 SPI 接口 。 下 面 的 例子 展示 了 如 何 将 数 
字 加 起 来 : 
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CREATE FUNCTION add numbers (rows desired integer) 
RETURNS integer AS 
$$ 


mysum = 0 


cursor = plpy-.cursor ("SELECT * FROM 
generate series(1, %d) AS id" % (rows desired)) 


while True: 
Tows = cursor.fetch(rows desired) 
if not rows: 
break 
for row in rows: 
mysum += row['id'] 
return mysum 
$$ LANGUAGE ‘plpythonu'; 


在 试验 这 个 例子 时 ， 要 确保 对 游标 的 调用 确实 在 单行 中 。Python 依赖 于 缩 进 ， 因 此 
代码 由 一 行 还 是 两 行 组 成 会 完全 不 同 。 

一 旦 游标 被 创建 ， 我 们 可 以 在 其 上 进行 循环 并 且 把 那些 数字 加 起 来 。 那 些 行 中 的 列 
可 以 通过 使 用 列 名 很 容易 地 引用 。 

调用 该 函数 将 返回 想 要 的 结果 : 

test=# SELECT add numbers (10) > 

add numbers 


(1 row) 


如 果 用 户 想 要 检查 一 个 SQL 语句 的 结果 集 ，PL/Python 提供 了 多 种 函数 从 结果 中 检索 
更 多 信息 。 再 一 次 ， 这 些 函 数 都 是 对 SPI 提 供 的 C 层 函 数 的 包装 。 
下 面 的 函数 会 更 近 距 离 地 检查 结果 : 


CREATE OR REPLACE FUNCTION result diag(rows desired integer) 
RETURNS integer AS 
$$ 
rv = plpy.execute ("SELECT * 
FROM generate series(1, %d) AS id" $ (rows desired)) 
plpy.noticel(rv.nrows()) 
plpy.noticel(rv.status()) 
plpy.notice(rv.colnames ()) 
plpy.noticel(rv.coltypes ()) 
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plpy.notice(rv.coltypmods () ) 
plpy.notice(rv. str ()) 


return 0 
$$ LANGUAGE '‘'plpythonu'; 


nrows 函数 将 显示 行 数 。status 函数 告诉 我 们 是 否 一 切 正常 。colnames 函数 返回 列 的 
一 个 列表 。coltypes 函数 返回 结果 集中 数据 类 型 的 对 象 ID，23 是 整数 的 内 部 编号 : 


test=# SELECT typname FROM pg type WHERE oid = 23; 
typname 





然后 是 typmod。 考 虑 varchar(20) 这 样 的 类 型 ， 其 中 的 配置 部 分 说 明了 类 型 有 什么 样 
的 typmod。 

最 后 有 一 个 函数 把 全 部 信息 作为 一 个 字符 串 返 回 用 于 调试 目的 ， 调 用 这 个 函数 将 返 
回 下 列 结果 : 

test=# SELECT result diag(3) 7 

NOTICE: 3 

NOTICE: 5 

NOTICE: ["i1d"] 

NOTICE: [23] 

NOTICE: [-1] 

NOTICE: <PLyResult status=5 nrows=3 rows=[{'id': 1}, 

eds 刘 贡 二 于 出 民 
result diag 


(1 row) 

在 SPI 接 口中 有 更 多 的 函数 来 帮助 执行 SQL。 

3. 处 理 错 误 

有 了 时， 用 户 可 能 必须 捕捉 错误 。 当 然 ， 这 在 Python 中 也 是 可 以 做 到 的 。 下 面 的 例子 
展示 了 如 何 捕获 错误 : 


CREATE OR REPLACE FUNCTION trial error() 
RETURNS text AS 


$$ 
ee 
rv = plpy-execute("SELECT surely a syntax error") 
except plpy.SsPIError: 
return "we caught the error" 
else: 
return "all fine" 
$$ LANGUAGE ‘plpythonu'; 


用 户 可 以 使 用 正常 的 try/except 块 并 且 访 问 plpy 来 处 理想 要 捕获 的 错误 ， 然 后 函数 可 
以 正常 返回 而 不 毁 掉 事务 : 


test=# SELECT trial error(); 
trial error 








we caught the error 
(1 row) 
记 住 ，PL/Python 能 完全 访问 PostgreSQL 的 内 部 。 因 此 ， 它 还 可 能 暴露 所 有 类 型 的 错 
误 给 用 户 的 过 程 。 这 里 有 一 个 例子 : 
except spiexceptions.DivisionByZero: 
return "found a division by zero" 
except spiexceptions.UniqueViolation: 
return "found a unique violation" 


except plpy.SsSPIError, e: 
return "other error, SQLSTATE %s" % e.sqlstate 


在 Python 中 捕捉 错误 确实 很 容易 并 且 能 帮助 防止 函数 失败 。 
7.3 改进 存储 过 程 的 性 能 


到 目前 为 止 ， 读 者 已 经 见 过 了 如 何 用 多 种 语言 编写 基本 的 存储 过 程 以 及 触发 器 。 
当然 ， 有 更 多 的 语言 被 支持 。 一 些 最 突出 的 包括 PL/R (R 是 一 种 强大 的 统计 包 ) 以 及 
PL/v8〈 基 于 Google JavaScript 引擎 ) 。 不 过 ， 那 些 语言 超过 了 本 章 的 范围 ( 先 不 管 它们 是 
否 有 用 ) 。 

本 节 将 聚焦 于 提高 存储 过 程 的 性 能 。 可 以 在 若干 领域 加 速 存储 过 程 的 处 理 : 

@ ”减少 调用 次 数 。 

@ ”使 用 缓存 计划 。 

@ 给 优化 器 提示 。 
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在 本 章 中 将 讨论 这 3 个 主要 领域 。 

@ ”减少 函数 调用 次 数 

在 很 多 情况 下 ， 性 能 不 好 是 因为 函数 被 过 于 频繁 地 调用 。 有 一 点 再 怎么 强调 也 不 为 
过 ， 过 于 频繁 地 调用 是 性 能 不 好 的 主因 。 在 创建 一 个 函数 时 ， 用 户 可 以 选择 3 种 类 型 的 
函数 : volatile、stable 以 及 immutable。 这 里 有 一 个 例子 : 








test=# SELECT random(), random(); 


random | random 

Sa A ee 

0.276252629235387 | 0.710661871358752 

(1 row) 
test=# SELECT now(), now(); 

now | now 

RR ER rN A ee A a Seda 
O016=12=16 12257517.13575Lt0E | 2016=12=16 122575L7.13575L+01 
(1 row) 


test=# SELECT pi(); 
pi 


3.14159265358979 

(1 row) 

volatile 函数 意味 着 该 函数 不 能 被 优化 掉 ， 它 不 得 不 被 一 次 又 一 次 地 执行 。volatile 函 
数 还 可 能 是 为 什么 没有 使 用 一 个 特定 索引 的 原因 。 默 认 情况 下 ， 每 一 个 函数 都 被 认为 是 
volatile。stable 函数 在 同一 个 事务 中 将 总 是 返回 相同 的 数据 。 它 可 以 被 优化 并 且 调 用 可 以 被 
移 除 。now 函数 是 stable 函数 的 一 个 绝 佳 例子 ， 在 同一 个 事务 中 它 总 是 返回 相同 的 数据 。 

immutable 函数 是 黄金 标准 ， 因 为 它们 允许 进行 大 部 分 优化 ， 那 是 因为 它们 总 是 对 给 
定 的 相同 输入 返回 相同 的 结果 。 作 为 优化 函数 的 第 一 步 ， 要 总 是 确保 在 定义 它们 时 用 
volatile 、stable 或 者 immutable 正确 地 标记 它们 。 


1 使 用 缓存 计划 


在 PostgreSQL 中 ， 查 询 被 分 成 4 个 阶段 执行 。 
@ 解析 器 : 检查 语法 。 

重 写 系统 ， 处理 规 则 等 。 
优化 器 /规划 器 : 优化 查询 。 

执行 器 ， 执 行规 划 器 提供 的 计划 。 
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如 果 查 询 很 短 ， 前 3 步 相 对 于 实际 执行 时 间 来 说 更 耗 时 。 因 此 ， 有 必要 缓存 执行 计 
划 。PL/pgSQL 基本 上 会 在 幕后 自动 缓存 所 有 的 计划 ， 用 户 无 须 操 心 。PL/Perl 和 
PL/Python 则 会 让 用 户 选 择 。SPI 接口 提供 了 处 理 和 运行 预备 查询 的 函数 ， 因 此 程序 员 可 以 
选择 查询 是 否 应 该 被 预备 。 在 查询 很 长 的 情况 下 ， 可 能 确实 有 必要 使 用 非 预备 查询 一 一 但 
短 查询 通常 应 该 总 是 被 预备 以 减 小 内 部 开销 。 


2， 为 函数 指派 代价 


从 优化 器 的 角度 来 看 ， 一 个 函数 基本 上 就 像 是 一 个 操作 符 。PostgreSQL 也 将 以 同样 
的 方式 处 理 代 价 ， 就 好 像 它 是 一 个 标准 的 操作 符 。 只 是 问题 在 于 : 加 两 个 数 通常 比 使 用 
某 个 PostGIS 提供 的 函数 做 海岸 线 相 交代 价 更 低 。 原 因 就 在 于 优化 器 不 知道 一 个 函数 是 便 
宜 还 是 昂贵 。 幸 运 的 是 ， 我 们 可 以 告诉 优化 器 让 函数 变 得 更 便宜 或 者 更 昂贵 : 

test=# h CREATE FUNCTION 


Command: CREATE FUNCTION 
Description: define a new function 











Syntax: 
CREATE [ OR REPLACE ] FUNCTION 


| COST execution cost 
| ROWS result rows 


COST 参数 表示 用 户 的 操作 符 实际 比 标准 操作 符 贵 多 少 。 它 是 一 个 用 于 cpu_operator_ 
cost 的 乘 数 而 不 是 一 个 静态 值 。 通 常 ， 除 非 函数 由 C 写成 ， 默 认 值 是 100。 

第 二 个 参数 是 ROWS 函数 。PostgreSQL 默认 假设 集合 返回 函数 将 返回 1000 行 ， 因 为 
系统 无 法 精确 地 确定 到 底 有 多 少 行 。ROWS 参数 允许 开发 者 告诉 PostgreSQL 预期 的 行 数 。 


7.4 使 用 存储 过 程 


在 PostgreSQL 中 ， 存 储 过 程 可 以 被 用 于 很 多 事情 。 在 本 章 中 ， 读 者 已 经 学 到 了 
CREATE DOMAIN 子 句 等 ， 但 还 可 以 创建 用 户 自己 的 操作 符 、 类 型 转换 甚至 排序 规则 。 

在 本 节 中 ， 读 者 将 看 到 如 何 创建 一 个 简单 的 类 型 转换 以 及 如 何 用 它 来 获 益 。 为 了 定 
义 类 型 转换 ， 考 虑 一 下 CREATE CAST 子 句 : 

test=# h CREATE CAST 


Command: CREATE CAST 


Description: define a new cast 
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Syntax: 

CREATE CAST (source type AS target type) 
WITH FUNCTION function name (argument type [, ...]) 
[ AS ASSIGNMENT | AS IMPLICIT ] 


CREATE CAST (source type AS target type) 
WITHOUT FUNCTION 
[ AS ASSIGNMENT | AS IMPLICIT ] 


CREATE CAST (source type AS target type) 
WITH INOUT 
[ AS ASSIGNMENT AS IMPLICIT ] 
使 用 它 非常 简单 。 用 户 只 要 告诉 PostgreSQL 它 会 调用 哪个 过 程 把 何 种 类 型 转换 成 用 
户 想 要 的 数据 类 型 即 可 。 
在 标准 的 PostgreSQL 中 ， 用 户 无 法 把 一 个 人 P 地 址 转换 成 布尔 值 。 因 此 ， 这 就 是 一 个 
很 好 的 例子 。 首 先 必须 定义 存储 过 程 : 
CREATE FUNCTION inet to boolean (inet) 


RETURNS boolean AS 
$$ 





BEGIN 
RETURN true; 
END; 
$$ LANGUAGE '‘'plpgsql'; 
为 了 简单 ， 它 返回 真 。 不 过 ， 用 户 可 以 使 用 任何 语言 的 任何 代码 〈 当 然 ) 来 做 真正 
的 转换 。 
在 下 一 步 ， 已 经 可 以 定义 类 型 转换 : 
CREATE CAST (inet AS boolean) 
WITH FUNCTION inet to boolean (inet) 
AS IMPLICIT; 
第 一 件 事 是 告诉 PostgreSQL， 我 们 想 要 把 inet 转换 成 boolean。 然 后 该 函数 被 列 出 ， 
并 且 告 诉 PostgreSQL 要 隐 式 转换 。 
这 种 转换 是 一 种 直接 的 处 理 ， 我 们 可 以 测试 这 个 转换 : 
test=# SELECT '192.168.0.34'::inet::boolean; 
bool 
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1 
(1 row) 


基本 上 ， 同 样 的 逻辑 也 可 以 被 应 用 于 定义 排序 规则 。 同 样 ， 一 个 存储 过 程 还 可 以 被 
来 执行 任何 需要 完成 的 工作 : 
test=# h CREATE COLLATION 


Command: CREATE COLLATION 
Description: define a new collation 














rn 





Syntax: 
CREATE COLLATION name ( 
[ LOCALE = locale, ] 
[ LC COLLATE = lc collate, ] 
L LG CTYPE = Le ctype ] 
) 
CREATE COLLATION name FROM existing collation 


75 总 结 


在 本 章 中 ， 读 者 学 到 了 如 何 编写 存储 过 程 。 在 一 番 理 论 性 的 介绍 后 ， 我 们 的 注意 力 
集中 在 PL/pgSQL 的 某 些 特性 上 。 此 外 ， 读 者 还 学 到 了 如 何 使 用 PL/Perl 以 及 PL/Python， 
它们 是 PostgreSQL 提供 的 两 种 重要 语言 。 当 然 ， 还 有 更 多 的 语言 可 用 。 但 是 ， 由 于 本 书 
的 范围 《和 篇 幅 ) 限制 ， 无 法 详细 介绍 它们 。 如 果 读 者 想 要 了 解 更 多 ， 可 以 看 看 下 面 的 
网 站 : https://wiki.postgresql.org/wiki/PL_Matrix。 

在 第 8 章 中 ， 读 者 将 学 习 有 关 PostgreSQL 安全 性 的 内 容 ， 以 及 从 总 体 上 学 习 如 何 管 
理 用 户 和 权限 。 此 外 ， 读 者 还 将 学 习 有 关 网 络 安全 的 内 容 。 
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第 7 章 的 内 容 全 都 与 存储 过 程 和 编写 服务 器 端 代 码 有 关 。 在 向 读者 介绍 了 很 多 重要 
主题 之 后 ， 现 在 是 时 候 将 我 们 的 焦点 转向 PostgreSQL 的 安全 性 了 。 读 者 将 学 到 如 何 保护 
服务 器 以 及 配置 权限 。 

本 章 将 涵盖 下 列 主题 : 

@ 配置 网 络 访问 。 

@ 管理 认证 。 

@ ”处 理 用 户 和 角色 。 
@ 配置 数据 库 安 全 性 。 
@ 管理 方案 、 表 和 列 。 
© 
在 





行 级 安全 性 。 
本 章 结束 时 ， 读 者 将 能 够 配置 和 管理 PostgreSQL 的 安全 性 ?。 


8.1 管理 网 络 安全 性 


在 进入 真实 世界 的 实际 例子 之 前 ， 笔 者 想 把 读者 的 注意 力 稍稍 转向 我 们 将 要 处 理 的 
多 个 安全 性 层次 。 在 处 理 安全 性 时 ， 有 必要 把 这 些 层次 记 在 心里 以 便 有 条 理 地 解决 与 安 
全 性 相关 的 问题 。 
下 面 是 笔者 心目 中 的 安全 性 层次 模型 。 
@ 绑 定 地 址 : postgresqlLconf 文件 中 的 listen_ addresses。 
基于 主机 的 访问 控制 : pg_hba.conf 文 件 。 
实例 级 权限 : 用 户 、 角 色 、 数 据 库 创建 、 登 录 以 及 复制 。 
数据 库 级 权限 : 连接 、 创 建 方案 等 。 
方案 级 权限 : 使 用 方案 以 及 在 方案 中 创建 对 象 。 
表 级 权限 : 选择 、 插 入 、 更 新 等 。 
列 级 权限 : 允许 或 者 限制 对 列 的 访问 。 





@ 原文 此 处 是 “At the end of the chapter, you will be able to write good and efficient procedures.”， 这 和 第 7 章 对 应 位 置 的 句子 
完全 相同 ， 显 然 这 一 章 的 内 容 是 关于 安全 性 而 不 是 存储 过 程 ， 因 此 原文 应 为 笔 误 。 这 里 译 者 按照 原作 者 的 风格 加 上 了 一 个 
类 似 的 句子 。 
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@ 行 级 安全 性 : 限制 对 行 的 访问 。 
为 了 读 取 一 个 值 ，PostgreSQL 必须 确定 用 户 在 每 一 个 级 别 上 具有 足够 的 权限 ， 整 个 
权限 链 必 须 正 确 。 


8.1.1 理解 绑 定 地 址 和 连接 


在 配置 PostereSQL 服务 器 时 ， 首 先 要 做 的 事情 之 一 是 定义 远程 访问 ， 默 认 PostgreSQL 
不 接受 远程 连接 。 这 里 的 重点 是 PostgreSQL 甚至 都 没有 机 会 拒绝 连接 ， 因 为 它 根本 没有 
在 端口 上 监听 。 如 果 用 户 尝试 连接 ， 错 误 消息 实际 上 将 由 操作 系统 返回 ， 因 为 PostgreSQL 
根本 就 没有 关心 远程 连接 。 

假定 有 一 台数 据 库 服务 器 在 192.168.0.123 上 使 用 默认 配置 ， 将 发 生 下 面 的 效果 : 

iMac:~ hs$ telnet 192.168.0.123 5432 

Trying i li92-16820-123.. 


telnet: connect to address 192.168.0.123: Connection refused 
telnet: Unable to connect to remote host 


telnet 尝试 在 端口 5432 上 创建 一 个 连接 ， 并 且 将 立即 被 远 端 的 机 器 拒绝 。 从 外 部 来 
就 好 像 PostgreSQL 根本 没有 运行 。 
成 功 的 关键 可 以 在 postgresql.conf 文 件 中 找到 : 


# - Connection Settings 一 











六 


#1listen addresses = 'localhost" 
# what IP address(es) to listen on; 
# comma-separated list of addresses; 
# defaults to 'localhost'; use '*' for all 
# (change requires restart) 


listen_addresses 设置 将 告诉 PostgreSQL 要 在 哪些 地 址 上 监听 。 从 技术 上 来 讲 ， 那 些 
地 址 就 是 绑 定 地 址 。 那 实际 意味 着 什么 ? 假定 用 户 的 机 器 上 有 4 块 网 卡 ， 用 户 可 以 在 那 
些 人 P 地 址 中 的 3 个 上 监听 。 了 PostgreSQL 会 考虑 对 那 3 块 网 卡 的 请 求 并 且 不 在 第 4 块 上 监 
听 ， 在 第 4 块 网 卡 上 端口 根本 就 是 关闭 的 。 

















9 用 户 必 须 将 其 服务 器 的 四 地址 而 不 是 客户 端的 四 放 入 listen addresses。 


如 果 在 其 中 放 入 一 个 '*"，PostereSQL 将 在 机 器 的 每 一 个 耳 上 监听 。 


é% 记 住 更 改 listen addresses 要 求 一 次 PostgreSQL 服务 重启 。 如 果 没 有 重启 ， 
它 不 能 被 即时 改变 。 
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不 过 ， 还 有 更 多 与 连接 管理 相关 的 设置 非常 有 必要 去 理解 : 


#port = 5432 
# (change requires restart) 
max connections = 100 
# (change requires restart) 
# Note: Increasing max connections costs ~400 bytes of 


# shared memory per 
# connection slot, plus lock space 
# (see max locks per transaction). 


#superuser reserved connections = 3 
# (change requires restart) 

#unix socket directories = '/tmp' 
# comma-separated list of directories 
# (change requires restart) 

#unix socket group = "'" 
# (change requires restart) 

#unix socket permissions = 0777 
# begin with 0 to use octal notation 
# (change requires restart) 


首先 ，PostgreSQL 对 一 个 单一 TCP 端口 (默认 值 是 5432) 监听。 记 住 PostgreSQL 
将 只 在 单个 端口 上 监听 。 只 要 一 个 请 求 进来 ，postmaster 将 会 派生 并 且 创 建 一 个 新 进程 来 
处 理 该 连接 。 默 认 情况 下 允许 最 多 100 个 普通 连接 。 此 外 ， 为 超级 用 户 保留 了 3 个 额外 
的 连接 。 这 就 意味 着 可 以 有 100 个 连接 外 加 3 个 超级 用 户 或 者 103 个 超级 用 户 连接 。 注 意 
那些 连接 相关 的 设置 也 将 需要 一 次 重启 ， 其 原因 是 在 共享 内 存 中 为 连接 分 配 的 是 静态 数 
量 的 内 存 ， 这 无 法 被 即时 更 改 。 

1. 检查 连接 和 性 能 

在 笔者 做 咨询 时 ， 很 多 人 问 到 提高 连接 限制 是 否 将 会 对 总 体 性 能 造成 影响 。 答 案 
是 : 影响 不 会 太 大 〈 总 是 会 有 一 些 上 下 文 切 换 等 造成 的 开销 ) 。 有 多 少 连接 基本 上 不 会 
造成 什么 区 别 。 不 过 ， 真 正 造成 不 同 的 是 打开 快照 的 数量 。 打 开 快照 〈 不 是 连接 ) 的 数 
量 越 多 ， 服 务 器 端的 开销 就 越 大 。 换 句 话 说， 用 户 增加 max_connections 的 代价 很 低 。 

如 果 读 者 对 一 些 真实 世界 的 数据 感 兴趣 ， 考 虑 看 看 笔者 的 一 篇 老 博文 : http:/www-.cybertec. 


at/max_connections-performance-impacts/。 


2. 不 使 用 TCP 的 世界 
在 某 些 情况 下 ， 用 户 可 能 不 想 使 用 网 络 ， 这 常常 发 生 在 数据 库 与 本 地 应 用 交互 的 场 
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景 中 。 也 许 ， 用 户 的 PostgreSQL 数据 库 是 与 应 用 一 起 发 售 的 ， 或 者 也 许 用 户 不 想 冒 使 用 
网 络 的 风险 : 在 这 种 情况 下 ， 就 需要 Unix 套 接 字 。Unix 套 接 字 是 一 种 无 须 网 络 的 通信 方 
法 。 用 户 的 应 用 可 以 通过 一 个 Unix 套 接 字 进行 本 地 的 连接 而 不 对 外 暴露 任何 东西 。 

不 过 ， 用 户 所 需要 的 只 是 一 个 目录 。PostgreSQL 默认 将 使 用 /tmp 目录 9?。 但 是 ， 如 果 
每 台 机 器 上 运行 不 止 一 个 数据 库 服务 器 ， 每 一 个 数据 库 服务 器 都 将 需要 一 个 单独 的 数据 
目录 。 

除了 安全 性 ， 还 有 很 多 不 使 用 网 络 的 理由 。 其 中 之 一 是 性 能 。 使 用 Unix 套 接 字 比 通 
过 环 回 设备 〈127.0.0.1) 快 很 多 。 如 果 读 者 对 此 感到 惊讶 ， 别 担心 一 一 很 多 人 都 和 你 一 
样 。 不 管 怎样 ， 如 果 只 运行 非常 小 的 查询 ， 真 实 网 络 连接 的 开销 不 应 该 被 低估 。 

为 了 向 读者 展示 这 到 底 意味 着 什么 ， 笔 者 在 这 里 包括 了 一 个 简单 的 基准 。 

笔者 已 经 创建 了 一 个 script.sql 文件 。 这 是 一 个 简单 的 脚本 ， 它 只 是 创建 一 个 随机 数 
并 且 选 择 这 个 数 。 因 此 它 可 能 是 最 简单 的 语句 了 ， 没 有 什么 比 只 取 一 个 数 更 简单 。 

如 此 ， 让 我 们 在 一 台 普 通 的 笔记 本 上 运行 这 个 简单 的 基准 。 为 了 运行 基准 ， 笔 者 已 
经 写 好 了 一 个 小 东西 script.sql， 它 将 会 被 该 基准 用 到 : 

[hselinuxpc ~]$ cat /tmp/script.sql 

SELECT 1 

然后 就 可 以 简单 地 运行 pgbench 来 一 遍 又 一 遍地 执行 这 个 SQL。-f 选项 允许 把 脚本 的 
名 字 传 给 pgbench。-c 10 表示 我 们 想 要 10 个 并 发 连接 并 且 连 接 会 活跃 5 秒 (-T 5) 。 这 个 
基准 被 作为 postgres 用 户 运 行 并 且 被 假定 使 用 postgres 数据 库 ， 该 数据 库 应 该 默认 存在 。 
注意 下 面 的 例子 将 能 在 RHEL 衍生 系统 上 运行 ， 基 于 Debian 的 系统 将 使 用 不 同 的 路 径 : 

[hs@linuxpc ~]$ /usr/pgsql-9.6/bin/pgbench -f /tmp/script.sql 


= 0 9 
-U postgres postgres 2> /dev/null 

















transaction type: /tmp/script.sql 

scaling factor: 1 

query mode: simple 

number of clients: 10 

number of threads: 1 

duration: 5 s 

number of transactions actually processed: 871407 
latency average = 0.057 ms 

tps = 174278.158426 (including connections establishing) 
tps = 174377.935625 (excluding connections establishing) 





9 原文 是 “command”， 应 为 笔 误 。 
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如 你 所 见 ， 没 有 向 pgbench 传递 主机 名 ， 因 此 这 个 工具 本 地 连接 到 Unix 套 接 字 并 且 
尽 可 能 快 地 运行 该 脚本 。 在 这 个 四 核 的 Intel 机 器 上 ， 系 统 能 够 达到 每 秒 174000 个 事务 。 
如 果 加 上 -h localhost 会 发 生 什么 ? 


[hselinuxpc ~]$ /usr/pgsql-9.6/bin/pgbench -f /tmp/script.sql 
= ocathost =e LO =T 5 
-U postgres postgres 2> /dev/null 

transaction type: /tmp/script.sql 

scaling factor: 1 








query mode: simple 

number of clients: 10 

number of threads: 1 

duration: 5 s 

number of transactions actually processed: 535251 
latency average = 0.093 ms 

tps = 107000.872598 (including connections establishing) 
tps = 107046.943632 (excluding connections establishing) 


吞吐 量 将 跌落 到 每 秒 107000 个 事务 。 区 别 很 明显 与 网 络 开 销 有 关 。 
通过 使 用 -j 选项 ( 分 派 给 pgbench 的 线程 数 )， 用 户 可 以 把 更 多 的 事务 挤 出 
系统 外 。 但 是 ， 在 笔者 的 情况 中 这 并 不 会 改变 该 基准 的 总 体 结果 。 在 其 他 的 测 
试 中 ， 它 确实 会 造成 改变 ， 因 为 如 果 没 有 提供 足够 的 CPU 能 力 ，pgbench 可 能 
会 是 一 个 真正 的 瓶颈 。 


如 你 所 见 ， 网 络 可 能 不 只 是 一 种 安全 性 问题 ， 还 可 能 是 一 种 性 能 问题 。 
8.1.2 ”管理 pg_hba.conf 


在 配置 好 绑 定 地 址 之 后 ， 就 可 以 转 到 下 一 个 级 别 。pg_hba.conf 文件 将 告诉 PostgreSQL 
如 何 认证 来 自 网 络 的 用 户 。 通 常 ，pg_hba.conf 文件 项 具有 下 面 的 格式 ， 

# local DATABASE USER METHOD [OPTIONS] 

# host DATABASE USER ADDRESS METHOD [OPTIONS] 


# hostssl DATABASE USER ADDRESS METHOD [OPTIONS] 
# hostnossl DATABASE USER ADDRESS METHOD [OPTIONS] 


可 以 在 pg_ hba.conf 文 件 中 放 入 以 下 4 类 规则 。 

@ local: 可 以 被 用 来 配置 本 地 Unix 套 接 字 连接 。 

@ host: 可 以 被 用 于 SSL 和 非 SSL 连接 。 

@ hostssl: 只 可 用 于 SSL 连接 。 为 了 使 用 该 选项 ， 服 务 器 中 必须 编译 有 SSL， 
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PostgreSQL 的 预 包装 版 本 就 编译 有 SSL 。 此 外 ， 服 务 器 启动 时 必须 在 
postgresql.conf 文件 中 已 经 设置 有 ssl = on。 
hostnossl: 用 于 非 SSL 连接 。 


一 个 规则 列表 可 以 被 放 在 pg_hba.conf 文 件 中 。 这 里 是 一 个 例子 : 


# TYPE DATABASE USER ADDRESS METHOD 
local all all trust 
host all all L2750=:05T/32 trust 
host all all a ele: trust 


可 以 看 到 3 条 简单 的 规则 。local 记录 说 明 要 访问 所 有 数据 库 的 来 自 本 地 Unix 套 接 字 
的 所 有 用 户 都 被 信任 。trust 方法 意味 着 不 会 有 口令 被 发 送 到 服务 器 并 且 人 们 可 以 直接 登 
录 。 其 他 两 个 规则 说 明 将 同样 的 方法 应 用 在 来 自 本 地 主机 127.0.0.1 和 ::1/128 (这 是 一 个 
IPv6 连接 ) 的 连接 上 。 




















] 于 不 用 口令 连接 肯定 不 是 远程 访问 最 好 的 选择 ，PostgreSQL 提供 了 多 种 认证 方法 


以 便 更 灵活 地 配置 pg_hba.conf 文件 。 下 面 是 可 能 的 认证 方法 列表 。 


trust: 允许 不 提供 密码 的 认证 。 要 求 用 户 必须 在 PostgreSQL 端 可 用 。 
reject: 连接 将 被 拒绝 。 

md5 和 password: 连接 可 以 使 用 口令 创建 。md5 意味 着 口令 在 线 缆 上 发 送 时 被 加 
密 。 在 password 的 情况 下 ， 赁 证 被 以 明文 发 送 ， 在 现代 系统 中 不 应 该 这 样 做 。 
GSS 和 SSPI: 这 种 方法 使 用 GSSAPI 或 SSPI 认证 。 这 种 方法 只 对 TCP/IP 连接 
可 用 。 其 想法 是 允许 单 点 登录 。 

ident: 这 种 方法 通过 联系 客户 端 上 的 Ident 服务 器 获得 客户 端的 操作 系统 用 户 
名 ， 并 且 检 查 它 是 否 匹 配 被 请 求 的 数据 库 用 户 名 。 

peer: 假定 用 于 作为 abc 登录 Unix。 如 果 启 用 peer， 用 户 就 只 能 作为 abc 登录 
PostgreSQL。 如 果 用 户 尝试 更 改 用 户 名 ， 它 将 被 拒绝 。 这 里 好 的 一 点 是 abc 将 不 
需要 口令 进行 认证 。 其 思想 是 只 有 数据 库 管 理 员 能 登录 Unix 系统 上 的 数据 库 ， 而 
其 他 只 有 口令 或 者 同一 机 器 上 Unix 账户 的 人 则 不 能 登录 。 这 只 对 本 地 连接 有 用 。 
pam: 它 使 用 可 插 拔 认证 模块 PAM) 。 如 果 想 要 使 用 一 种 不 是 PostgreSQL 自 
带 的 认证 方式 ， 这 就 特别 重要 。 要 使 用 PAM， 在 Linux 系统 上 创建 文件 
/etc/pam.d/postgresql， 并 且 把 计划 要 使 用 的 PAM 模块 放 在 这 个 配置 文件 中 。 通 
过 使 用 PAM， 甚 至 可 以 使 用 不 常见 的 组 件 进行 认证 。 不 过 ， 它 也 能 被 用 来 连接 
到 活动 目录 等 服务 。 

ldap: 这 种 配置 允许 用 户 使 用 轻 量 级 目录 访问 协议 LDAP) 进行 认证 。 注 意 
PostgreSQL 将 只 请 求 LDAP 认证 ， 如 果 一 个 用 户 只 存在 于 LDAP 上 但 不 存在 于 
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PostgreSQL 这 边 ， 用 户 就 不 能 登录 。 还 要 注意 PostgreSQL 必须 知道 LDAP 服务 
器 在 哪里 。 所 有 这 些 信息 都 必须 被 存放 在 pg_hba.conf 文件 中 ， 具 体 可 见 官方 文 
档 : https://www.postgresql.org/docs/9.6/static/auth-methods.html#AUTH-LDAP。 

@ radius: 远程 认证 拨 入 用 户 服务 (RADIUS) 是 一 种 实现 单 点 登录 的 方法 。 再 一 
次 ， 参 数 使 用 配置 选项 传 入 。 

@ cert: 这 种 认证 方法 使 用 SSL 客户 端 证 书 来 执行 认证 ， 因 此 只 有 使 用 SSL 才能 
用 它 。 这 里 的 优势 是 不 必要 发 送 口令 。 证 书 的 CN 属性 将 被 与 请 求 的 数据 库 用 户 
名 比较 ， 如 果 它 们 匹配 ， 登 录 将 被 允许 。 可 以 用 一 个 映射 来 允许 用 户 映 射 。 

可 以 简单 地 一 个 接 一 个 地 列 出 规则 。 重 点 是 规则 的 顺序 确实 会 产生 区 别 ， 如 下 例 

所 示 : 


host all all 192.168-1.0/24 md5 
host all all IUD 2 Ga reject 


当 PostgreSQL 读 取 pg_hba.conf 文件 时 ， 它 将 使 用 匹配 上 的 第 一 条 规则 。 因 此 ， 如 果 
我 们 的 请 求 来 自 于 192.168.1.54， 第 一 条 规则 将 总 是 在 我 们 走 到 第 二 条 规则 之 前 就 匹配 
上 。 这 意味 着 如 果 口 令 和 用 户 正 确 ，192.168.1.54 将 能 登录 。 因 此 ， 第 二 条 规则 是 没有 意 
义 的 。 

如 果 想 要 排除 这 个 卫 ， 就 应 该 交换 这 两 条 规则 。 

@ 处 理 SSL 

PostgreSQL 允许 用 户 加 密 服 务 器 和 客户 端 之 间 的 传输 。 加 密 非常 有 益 ， 特 别 是 在 进 
行 长 距离 通信 时 。SSL 提供 了 一 种 简单 且 安 全 的 方式 来 确保 无 人 能 监听 通信 。 在 本 节 
中 ， 读 者 将 学 到 如 何 设置 SSL。 

第 一 件 要 做 的 事情 是 在 服务 器 启动 时 把 postgresql.conf 文件 中 的 ssl 参数 设置 为 on。 
下 一 步 ， 可 以 把 SSL 证 书 放 到 $PGDATA 目录 中 。 如 果 不 想 证 书 放 在 某 个 其 他 目录 中 ， 
请 更 改 下 列 参数 : 


#ss1 cert file = 'server.crt' 

















# (change requires restart) 
#ss1 key file = 'server.key' # (change requires restart) 
# 


#5ss1 ca file 三 (change requires restart) 


#ssl crl file = "" # (change requires restart) 
如 果 想 要 使 用 自 签名 证 书 ， 执 行 下 列 步 又: 
openssl] req -new -text -out server.req 


回答 OpenSSL 提出 的 问题 。 确 保 输入 本 地 主机 名 作为 common name。 可 以 将 口令 留 
空 。 这 个 调用 将 生成 一 个 被 口令 保护 的 密 钥 ， 它 将 不 会 接受 短 于 4 个 字符 的 口令 。 要 移 
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除 口令 (如 果 要 自动 启动 服务 器 就 必须 这 样 做 ) ， 运 行 命令 : 

openssl] rsa -in privkey.pem -out server.key 

rm privkey.pem 

输入 旧 的 口令 解锁 现 有 的 密 钥 。 现 在 执行 下 面 的 命令 将 该 证 书 转变 成 一 个 自 签名 证 
书 并 且 把 密 钥 和 证 书 复制 到 服务 器 查找 它们 的 地 方 : 


openssl req -x509 -in server.req -text 
-key server.key -out server.crt 


最 后 ， 确 保 这 些 文件 有 正确 的 权限 集 : 
chmod og-rwx server.key 


一 旦 正确 的 规则 被 放 入 pg_hba.conf 文件 ， 就 可 以 使 用 SSL 来 连接 服务 器 。 要 验证 的 
确 在 使 用 SSL， 考 虑 检查 pg_stat_ssl 函数 。 它 将 显示 每 一 个 连接 以 及 它们 是 否 使 用 SSL， 
并 且 它 将 提供 有 关 加 密 的 重要 信息 : 


test=# d pg_ stat ssl 








View "pg_catalog.pg_ stat ssl" 


Column 1 Type | Modifiers 
ey 全 0 EE 
pid | integer | 
ssl | boolean | 
version | text 
cipher | text 
bits | integer | 
compression | boolean | 
clientdn | text 


如 果 一 个 进程 的 ssl 域 包含 真 ， 那 么 PostgreSQL 就 已 经 开始 使 用 SSL: 


Postgres=# select * from pg stat ssl7 


GORDEIE 
pid 1 20075 
3 I 上 夺 
version 1 TLSV1.2 
cipher | ECDHE-RSA-AES256-GCM-SHA384 
bits | 256 
compression | f 
1 


clientdn 
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8.1.3 ”处 理 实例 级 安全 性 


到 目前 为 止 ， 我 们 已 经 配置 了 绑 定 地 址 并 且 我 们 已 经 告诉 PostgreSQL 对 哪些 卫 范围 
使 用 哪 种 认证 方法 。 至 今 ， 配 置 都 只 与 网 络 相 关 。 

下 一 步 ， 可 以 把 注意 力 转 到 实例 级 的 权限 。 最 重要 的 一 点 是 PostgreSQL 中 的 用 户 都 
存在 于 实例 级 。 如 果 创 建 一 个 用 户 ， 它 不 只 是 在 一 个 数据 库 中 可 见 一 一 它 可 以 被 所 有 的 
数据 库 看 见 。 一 个 用 户 可 能 只 有 访问 单一 数据 库 的 权限 ， 但 本 质 上 用 户 是 被 创建 在 实例 
级 别 。 

对 于 新 接触 PostgreSQL 的 人 ， 还 有 一 件 事情 应 该 记 住 一 一 用 户 和 角色 是 同一 种 东 
西 。CREATE ROLE 和 CREATE USER 子 句 有 不 同 的 默认 值 ( 正 确 地 说 ， 唯 一 的 区 别 是 
角色 默认 没有 LOGIN 属性 ) ， 但 总 而 言 之 ， 用 户 和 角色 是 相同 的 。 因 此 ，CREATE 
ROLE 和 CREATE USER 子 句 支持 非常 相似 的 语法 : 

test=# h CREATE USER 

Command: CREATE USER 

Description: define a new database role 


Syntax: 
CREATE USER name [ [ WITH ] option [ ... ] ] 

















where option can be: 


SUPERUSER | NOSUPERUSER 
CREATEDB | NOCREATEDB 
CREATEROLE | NOCREATEROLE 
INHERIT | NOINHERIT 

LOGIN | NOLOGIN 

REPLICATION | NOREPLICATION 
BYPASSRLS | NOBYPASSRLS 
CONNECTION LIMIT connlimit 
[ ENCRYPTED | UNENCRYPTED ] PASSWORD "password'" 
VALID UNTIL ‘timestamp'"' 

IN ROLE role name [, ...] 
IN GROUP role name [, ...] 
ROLE role name [, ...] 
ADMIN role name [, ...] 
USER role name [, ...] 
SYSID uid 


让 我 们 逐个 讨论 这 些 语法 元 素 。 第 一 点 是 用 户 可 以 是 一 个 超级 用 户 或 者 一 个 普通 用 
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户 。 如 果 某 个 人 被 标记 为 超级 用 户 ， 就 没有 普通 用 户 必须 面 对 的 任何 限制 。 超 级 用 户 可 
以 根据 其 意愿 删除 对 象 〈 数 据 库 等 ) 。 

下 一 个 重点 是 需要 有 实例 级 权限 来 创建 新 数据 库 。 注 意 当 某 个 人 创建 一 个 数据 库 
时 ， 这 个 用 户 将 自动 成 为 该 数据 库 的 拥有 者 。 规 则 是 : 创建 者 总 是 自动 地 成 为 对 象 的 拥 
有 者 除非 像 CREATE DATABASE 子 句 中 特别 指定 其 他 人 作为 拥有 者 ) 。 好 处 是 对 象 
拥有 者 还 可 以 再 次 删除 对 象 。 


0 CREATEROLE/NOCREATEROLE 子 句 定义 茶 个 人 是 否 被 允许 创建 新 用 户 / 
角色 。 


再 下 一 个 重点 是 INHERIT/NOINHERIT 子 句 。 如 果 INHERIT 子 句 被 设置 〈 默 认 值 ) ， 
用 户 可 以 从 某 个 其 他 用 户 继承 权限 。 使 用 继承 的 权限 允许 把 角色 用 作 一 种 抽象 权限 的 方 
法 。 例 如 ， 可 以 创建 一 个 会 计 员 的 角色 并 且 让 很 多 其 他 角色 从 会 计 员 继承 。 其 想法 在 
于 ， 即 使 有 很 多 人 都 在 做 会 计 工 作 ， 也 只 需要 告诉 PostgreSQL 一 次 会 计 员 能 做 什么 。 

LOGIN/NOLOGIN 子 句 定 义 一 个 角色 是 否 被 允许 登录 实例 。 注 意 ，LOGIN 子 句 并 不 
足以 实际 地 连接 到 一 个 数据 库 。 要 做 到 这 一 点 ， 还 需要 更 多 权限 。 目 前 ， 试 图 让 它 进 入 
实例 中 ，LOGIN 子 句 基本 上 是 实例 中 所 有 数据 库 的 大 门 。 让 我 们 回 到 我 们 的 例子 : 会 计 
员 可 能 被 标记 为 NOLOGIN， 因 为 我 们 想 让 人 们 用 他 们 的 真实 名 称 登录 。 所 有 的 会 计 〈 即 
joe 和 jane) 可 以 被 标记 为 LOGIN， 但 能 从 会 计 员 角色 继承 所 有 权限 。 

如 果 用 户 计划 运行 PostgreSQL 的 流 复制 ， 用 户 可 以 作为 超级 用 户 做 所 有 的 事务 日 志 
流 式 传送 。 但 是 ， 从 安全 性 的 角度 来 看 ， 不 推荐 这 样 做 。 为 了 确保 不 需要 使 用 超级 用 户 流 
式 传送 xlog，PostgreSQL 允许 把 复制 权限 给 予 普通 用 户 ， 之 后 它 就 能 被 用 来 做 流 式 传送 。 

正如 稍 后 在 本 章 中 将 要 看 到 的 那样 ，PostgreSQL 提供 一 种 称 为 行 级 安全 性 的 特性 。 
其 思想 是 可 以 从 一 个 用 户 的 视野 中 排除 行 。 如 果 用 户 被 明确 设 定 为 可 以 绕 过 RLS， 将 这 
个 值 设 置 为 BYPASSRLS。 默 认 值 是 NOBYPASSRLS。 

有 时 有 必要 限制 一 个 用 户 允 许 的 连接 数 。CONNECTION LIMIT 允许 做 这 样 的 限制 。 
注意 总 体 上 连接 数 绝 不 会 超过 postgresql.conf 文件 中 的 设置 (max connections) 。 但 是 可 
以 把 特定 用 户 限制 到 较 低 的 值 。 

默认 情况 下 ，PostgreSQL 将 在 系统 表 中 加 密 存 储 口令 ， 这 是 一 种 好 的 默认 行为 。 不 
过 ， 假 定 用 户 正 在 做 一 次 培训 课程 。10 个 学 生 参 加 并 且 每 个 人 都 被 连接 到 系统 中 。 我 们 
可 以 100% 肯 定 这 些 人 中 的 一 个 将 偶尔 忘记 他 /她 的 口令 。 由 于 用 户 的 设置 中 安全 性 并 非 关 
键 ， 用 户 可 能 决定 以 明文 存储 口令 ， 这 样 可 以 很 容易 地 查找 口令 并 且 把 它 告诉 学 生 。 如 
果 正 在 测试 软件 ， 这 种 特性 也 派 得 上 用 场 。 

我 们 常常 会 知道 某 人 将 很 快 离开 我 们 的 机 构 。VALID UNTIL 子 句 允许 我 们 在 一 个 特 
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定 用 户 的 账户 过 期 后 自动 锁 住 他 /她 。 
IN ROLE 列 出 一 个 或 者 更 多 现 有 的 角色 ， 新 角色 将 被 立即 加 入 它们 作为 新 成 员 ， 这 
有 助 于 避免 额外 的 手工 步骤 。IN ROLE 的 一 种 替代 方法 是 IN GROUP。 

ROLE 子 句 将 定义 被 自动 作为 新 角色 成 员 的 角色 。ADMIN 子 句 和 ROLE 子 句 相同 ， 
但 是 增加 了 WITH ADMIN OPTION。 

最 后 ， 可 以 使 用 SYSID 子 句 为 这 个 用 户 指定 一 个 特定 的 ID 〔〈 类 似 于 某 些 Unix 管理 
员 对 操作 系统 级 别 用 户 名 所 作 的 事情 ) 。 

@ ”创建 和 修改 用 户 

在 这 些 理论 介绍 之 后 ， 让 我 们 实际 创建 用 户 并 且 看 看 在 实际 的 例子 中 如 何 使 用 它们 : 

test=# CREATE ROLE bookkeeper NOLOGIN; 

CREATE ROLE 

test=# CREATE ROLE joe LOGIN; 

CREATE ROLE 

test=# GRANT bookkeeper TO joe; 

GRANT ROLE 

这 里 的 第 一 件 事 是 创建 了 一 个 名 为 bookkeeper 的 角色 。 注 意 我 们 并 不 想 让 人 们 以 
bookkeeper 登录 ， 因 此 该 角色 被 标记 为 NOLOGIN。 

人 还 要 注意 如 果 使 用 CREATE ROLE 子 句 ，NOLOGIN 是 默认 值 。 如 果 更 喜 




















欢 CREATE USER 子 句 ， 其 默认 设置 是 LOGIN。 


然后 ， 创 建 joe 角色 并 且 标 记 为 LOGIN。 最 后 ，bookkeeper 角色 被 指派 给 joe 角色 ， 
这 样 他 能 做 一 个 会 计 员 被 允许 做 的 所 有 事情 。 

一 旦 用 户 就 位 ， 我 们 可 以 对 已 有 的 用 户 进行 测试 : 

[hs@zenbook ~]$ psql test -U bookkeeper 

psql: FATAL: role "bookkeeper" is not permitted to log in 

不 出 所 料 ， 会 计 员 角 色 不 被 允许 登录 系统 。 如 果 joe 角色 尝试 会 怎样 ? 

[hsezenbook ~]$ psql test -U joe 

ED 

这 确实 起 到 了 预期 的 效果 。 不 过 ， 请 注意 命令 提示 已 经 发 生 了 改变 ， 这 只 是 
PostgreSQL 用 来 向 用 户 表示 用 户 不 是 作为 超级 用 户 登录 的 方法 。 

一 旦 一 个 用 户 被 创建 ， 就 可 能 需要 对 它 进行 修改 。 其 中 一 个 可 能 需要 修改 的 是 口 
令 。 在 PostgreSQL 中 ， 人 允许 用 户 修改 自己 的 口令 ， 可 以 这 样 做 : 
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test=> ALTER ROLE joe PASSWORD "abc'7 
ALTER ROLE 
test=> SELECT current user; 


Current user 


ALTER ROLE 子 句 (或 者 ALTER USER) 将 允许 用 户 更 改 大 部 分 在 用 户 创 建 时 设 定 
的 设置 。 不 过 ， 管 理 用 户 还 有 更 多 可 做 的 事情 。 在 很 多 情况 下 ， 我 们 想 要 为 一 个 用 户 指 
派 特殊 的 参数 。 使 用 ALTER USER 子 句 就 是 一 种 方法 : 


ALTER ROLE { role specification | ALL } 
[ IN DATABASE database name ] 
SET configuration parameter { TO | = } { value | DEFAULT } 
ALTER ROLE { role specification | ALL } 
[ IN DATABASE database name ] 
SET configuration parameter FROM CURRENT 
ALTER ROLE { role specification | ALL } 
[ IN DATABASE database name ] RESET configuration parameter 
ALTER ROLE { role specification | ALL } 
[ IN DATABASE database name ] RESET ALL 


这 种 语法 相当 简单 并 且 很 直接 。 为 了 向 读者 展示 这 确实 有 用 ， 笔 者 增加 了 一 个 真实 
世界 的 例子 。 假 定 Joe 刚 好 生活 在 毛里 求 斯 岛 上 。 当 他 登录 时 ， 即 便 他 的 数据 库 服务 器 位 
于 欧洲 ， 他 也 希望 设置 为 他 所 在 的 时 区 : 

test=> ALTER ROLE joe SET TimeZone = 'UTC-4'; 


ALTER ROLE 
test=> SELECT now(); 


2017-01-09 20:36:48.571584+01 
(1 row) 


test=> q 
[hs@zenbook ~]$ psql test -U joe 


test=> SELECT now(); 
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2017-01-09 23:36:53.357845+04 
(1 row) 


ALTER ROLE 子 句 将 修改 用 户 。 只 要 Joe 重新 连接 ， 就 已 经 为 他 设置 好 了 时 
&9 时 区 不 会 被 立即 改变 。 用 户 需 要 重新 连接 或 者 使 用 SET ... TO DEFAULT 
子 句 。 





区 


这 里 的 重点 是 这 种 修改 还 可 以 用 于 一 些 内 存 参 数 ， 例 如 本 书 早 前 已 经 涵盖 的 


Work_mem 等 。 
8.1.4 定义 数据 库 级 安全 性 


在 实例 级 上 配置 好 用 户 之 后 ， 现 在 可 以 深入 数据 库 级 ， 看 看 在 数据 库 级 可 以 做 些 什 
么 。 第 一 个 出 现 的 主要 问题 是 ， 我 们 明确 地 允许 Joe 登录 数据 库 实例 ， 但 是 是 谁 或 者 是 什 
么 让 Joe 真正 地 连接 到 其 中 一 个 数据 库 ? 用 户 可 能 并 不 想 让 Joe 访问 系统 中 的 所 有 数据 
库 。 限 制 对 特定 数据 库 的 访问 正 是 我 们 可 以 在 这 一 个 级 别 上 实现 的 特性 。 

对 于 数据 库 ， 可 以 使 用 GRANT 子 句 设置 下 列 权 限 : 

GRANT { { CREATE | CONNECT | TEMPORARY | TEMP } [, ...] 

| ALL [ PRIVILEGES ] } 
ON DATABASE database name [, ...] 
TO role specification [, ...] [ WITH GRANT OPTION ] 


在 数据 库 级 有 两 种 主要 的 权限 值得 密切 关注 。 

@ CREATE: 允许 某 个 人 在 数据 库 中 创建 方案 ， 注 意 ，CREATE 子 句 不 允许 创建 
表 ， 它 是 有 关 方 案 的 权限 。 在 PostgreSQL 中 ， 表 位 于 一 个 方案 中 ， 因 此 在 能 创 
建 表 之 前 必须 先 涉及 方案 级 别 。 

@ CONNECT: 允许 某 个 人 连接 到 一 个 数据 库 。 

现在 的 问题 是 ， 没 有 人 显 式 地 给 joe 角色 指派 CONNECT 权限 。 那 么 那些 权限 到 底 从 

何 而 来 ? 答案 是 : 有 一 个 名 为 public 的 东西 ， 它 和 Unix 世界 中 的 public 类 似 。 如 果 在 这 

个 世界 中 大 家 都 被 允许 做 某 事 ， 那 么 Joe 也 被 允许 ， 他 是 公众 的 一 部 分 。 

重点 是 从 能 被 删除 和 重 命名 这 一 点 来 看 ，public 并 不 是 一 个 角色 。 读 者 可 以 简单 地 把 

它 理解 成 等 效 于 系统 中 的 每 一 个 人 。 

为 此 ， 为 了 确保 不 是 每 一 个 人 都 能 在 任何 时 间 连 接 到 任意 数据 库 ， 可 能 不 得 不 从 公 

众 收 回 CONNECT。 要 做 到 这 一 点 ， 可 以 作为 超级 用 户 连 接 并 且 修 复 这 一 问题 : 


[hs@zenbook ~]$ psql test -U postgres 
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test=# REVOKE ALL ON DATABASE test FROM public; 
REVOKE 

test=# q 

[hs@zenbook ~]$ psql test -U joe 

psql: FATAL: permission denied for database "test" 
DETAIL: User does not have CONNECT privilege. 


如 你 所 见 ，joe 角色 不 再 被 允许 连接 。 此 时 只 有 超级 用 户 具 有 对 test 的 访问 。 
通常 ， 在 其 他 数据 库 被 创建 之 前 就 从 postgres 数据 库 中 收回 权限 是 一 个 不 错 的 主意 。 





这 一 概念 背后 的 思想 是 那些 权限 将 不 再 出 现在 那些 新 创建 的 数据 库 中 。 如 果 某 人 需要 对 
一 个 特定 数据 库 的 访问 ， 可 以 明确 地 授予 权限 ， 权 限 不 再 被 自动 授予 。 


如 果 想 要 允许 joe 角色 连接 到 test 数据 库 ， 可 以 作为 超级 用 户 尝试 下 面 的 命令 : 


[hs@zenbook ~]$ psql test -U postgres 


test=# GRANT CONNECT ON DATABASE test TO bookkeeper; 
GRANT 

test=# q 

[hs@zenbook ~]$ psql test -U joe 


Eesk=> 

基本 上 ， 这 里 有 两 种 选择 : 

@ ”可 以 直接 允许 joe 角色 ， 这 样 只 有 joe 角色 将 能 连接 。 

@ ”可 以 授予 权限 给 会 计 员 角 色 。 记 住 ，joe 角色 将 从 会 计 员 角色 继承 所 有 权限 ， 因 
此 如 果 想 让 所 有 会 计 都 能 连接 到 这 个 数据 库 ， 对 会 计 员 角 色 分 配 权限 好 像 是 一 
种 很 有 吸引 力 的 想法 。 

如 果 对 会 计 员 角色 授予 权限 ， 是 不 会 有 风险 的 ， 因 为 这 个 角色 起 初 就 不 被 允许 登录 


实例 ， 因 此 它 纯粹 是 作为 一 个 权限 的 来 源 而 已 。 


8.1.5 调整 方案 级 权限 


一 旦 配置 完了 数据 库 级 安全 性 ， 就 有 必要 看 看 方案 级 的 权限 。 
在 实际 进入 这 个 级 别 前 ， 笔 者 想 要 运行 一 个 小 测试 : 

test=> CREATE DATABASE test; 

ERROR: permission denied to create database 


test=> CREATE USER xy; 
ERROR: permission denied to create role 
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test=> CREATE SCHEMA sales; 

ERROR: permission denied for database test 

如 你 所 见 ，Joe 不 太 走 运 ， 除 了 允许 连接 到 数据 库 ， 他 基本 上 什么 都 做 不 了 。 
不 过 ， 有 一 个 小 例外 ， 这 会 让 很 多 人 吃惊 : 

test=> CREATE TABLE t broken (id int); 

CREATE TABLE 


test=> d 

List of relations 
Schema | Name | Type | Owner 
一 -一 -一 一 一 一 十 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 十 一 一 一 一 一 一 一 十 一 一 一 一 一 一 一 
public | t broken | table | joe 
(1 rows) 


默认 情况 下 ，public 被 允许 使 用 public 模式 ， 并 且 总 是 如 此 。 如 果 对 保护 数据 库 的 安 
全 特别 感 兴趣 ， 应 确保 这 一 问题 得 到 妥善 处 理 。 否 则 ， 普 通用 户 将 可 能 在 public 模式 中 
放 入 各 种 表 ， 最 后 整个 系统 设置 都 会 遭 严 。 还 要 记 住 如 果 某 人 被 允许 创建 对 象 ， 这 个 人 
就 是 它 的 拥有 者 。 拥 有 关系 意味 着 创建 者 自动 拥有 所 有 的 权限 〈 包 括 毁 掉 该 对 象 ) 。 

为 了 从 public 中 拿 走 那些 权限 ， 可 以 作为 超级 用 户 运行 下 面 的 命令 : 

test=# REVOKE ALL ON SCHEMA public FROM public; 

REVOKE 


从 现在 开始 ， 再 没有 人 能 在 没有 权限 的 情况 下 在 public 模式 中 放 东 西 : 


[hs@zenbook ~]$ psql test -U joe 


test=> CREATE TABLE t data (id int); 
ERROR: no schema has been selected to create in 
LINE 1: CREATE TABLE t data (id int); 


如 你 所 见 ， 这 个 命令 将 会 失败 。 这 里 的 重点 是 用 户 看 到 的 错误 消息 ，PostgreSQL 不 
知道 在 哪里 放 这 些 表 。 默 认 情 况 下 ， 它 将 尝试 把 表 放 入 下 列 方案 之 一 : 


test=> SHOW search path ; 
search path 


"$user", public 
(1 row) 


1 于 没有 一 个 名 叫 joe 的 方案 ， 那 么 就 不 能 把 表 放 入 其 中 ，PostgreSQL 将 尝试 public 
模式 。 由 于 没有 权限 ，PostgreSQL 将 抱怨 它 不 知道 把 表 放 在 哪里 。 
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如 果 表 被 明确 地 加 上 前 级 ， 情 况 将 立即 改变 : 

test=> CREATE TABLE public.t data (id int); 

ERROR: permission denied for schema public 

LINE 1: CREATE TABLE public.t data (id int); 

在 这 种 情况 下 ， 用 户 将 得 到 一 个 意料 之 中 的 错误 消息 。PostgreSQL 否决 了 对 public 
模式 的 访问 。 

下 一 个 逻辑 上 的 问题 是 ， 在 模式 级 别 上 可 以 设置 哪些 权限 以 给 予 joe 角色 更 多 能 力 ? 


GRANT { { CREATE | USAGE } [, ...] | ALL [ PRIVILEGES ] } 
ON SCHEMA schema name [, ...] 
TO role specification [, ...] [ WITH GRANT OPTION ] 


CREATE 意味 着 某 人 可 以 在 一 个 模式 中 放 入 对 象 。USAGE 表示 某 人 被 允许 进入 该 模 
。 注 意 进 入 模式 并 不 意味 着 可 以 真正 使 用 该 模式 中 的 东西 一 一 那些 权限 还 没有 被 定 
。 说 白 了 ， 这 只 表示 该 用 户 能 看 到 这 个 方案 的 系统 目录 项 而 已 。 

为 了 允许 joe 角色 访问 他 之 前 创建 的 表 ， 将 需要 下 列 命令 〈 以 超级 用 户 执行 ) : 


test=# GRANT USAGE ON SCHEMA public TO bookkeeper; 
GRANT 


现在 ，joe 角色 能 够 按照 预期 读 取 他 的 表 : 


[hs@zenbook ~]$ psql test -U joe 
test=> SELECT count (*) FROM t broken; 
count 


X 交 出 


(1 row) 

joe 角色 还 能 增加 和 修改 行 ， 因 为 他 恰好 是 这 个 表 的 拥有 者 。 不 过 ， 尽 管 他 已 经 能 做 
很 多 事情 ，joe 角色 还 不 够 强大 。 考 虑 下 列 语句 : 

test=> ALTER TABLE t broken RENAME TO t useful; 

ERROR: permission denied for schema public 

让 我 们 更 仔细 地 看 看 实际 的 错误 消息 。 如 你 所 见 ， 该 消息 抱怨 的 是 有 关 该 模式 上 的 
权限 ， 而 不 是 表 本 身上 的 权限 〈 记 住 ，joe 角色 拥有 该 表 ) 。 为 了 解决 这 个 问题 ， 就 必须 
在 模式 级 别 而 不 是 在 表 级 别 上 进行 处 理 。 请 作为 超级 用 户 运行 下 列 命令 : 


test=# GRANT CREATE ON SCHEMA public TO bookkeeper; 
GRANT 
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joe 角色 现在 可 以 把 他 的 表 的 名 称 改 成 一 个 更 有 用 的 名 称 : 

[hs@zenbook ~]$ psql test -U joe 

test=> ALTER TABLE t _ broken RENAME TO t useful; 

ALTER TABLE 

记 住 如 果 使 用 DDL， 这 就 是 必需 的 。 在 笔者 作为 PostgreSQL 支持 服务 提供 商 的 日 常 
工作 中 ， 笔 者 已 经 见 过 了 若干 这 一 点 导致 的 问题 。 


8.1.6 使 用 表 
在 处 理 完 绑 定 地 址 、 网 络 认证 、 用 户 、 数 据 库 和 方案 之 后 ， 最 后 我 们 来 到 了 数据 库 
级 别 。 下 面 的 片段 展示 了 对 于 一 个 表 可 以 设置 哪些 权限 : 


GRANT { { SELECT | INSERT | UPDATE | DELETE | TRUNCATE 
| REFERENCES | TRIGGER } 


[, ...] | ALL [ PRIVILEGES ] } 
ON { [ TABLE ] table name [, ...] 
| ALL TABLES IN SCHEMA schema name [, ...] } 
TO role specification [, ...] [ WITH GRANT OPTION ] 


下 面 逐 个 解释 一 下 那些 权限 。 

@ SELECT: 人 允许 用 户 读 表 。 

@ ”INSERT: 允许 用 户 向 表 加 入 行 ( 这 还 包括 复制 等 一 一 它 不 仅 与 INSERT 子 句 有 
关 ) 。 注 意 如 果 用 户 被 允许 插入 并 不 表示 就 自动 被 允许 读 取 。 要 读 取 自己 已 经 
插入 的 数据 ， 用 户 需 要 能 执行 SELECT 和 INSERT 子 句 。 

@ UPDATE: 修改 表 的 内 容 。 

DELETE: 被 用 来 从 表 中 移 除 行 。 

@ 。 TRUNCATE: 人 允许 用 户 使 用 TRUNCATE 子 句 。 注 意 ，DELETE 和 TRUNCATE 
子 句 是 两 种 单独 的 权限 ， 因 为 TRUNCATE 子 句 将 会 锁 表 ， 而 DELETE 子 句 不 
会 (即便 没有 WHERE 条 件 )。 

@ ”REFERENCES: 允许 创建 外 键 。 必 须 在 引用 列 和 被 引用 列 上 都 有 这 一 特权 ， 否 
则 无 法 创建 外 键 。 

@ TRIGGER: 人 允许 创建 触发 器 。 


(外 GRANT 子 句 有 一 个 好 处 是 可 以 同时 设置 一 个 方案 中 所 有 表 的 权限 。 


它 很 大 程度 上 简化 了 调整 权限 的 过 程 。 还 可 以 使 用 WITH GRANT OPTION 子 句 。 其 
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思想 在 于 确保 普通 用 户 可 以 把 权限 传递 给 其 他 用 户 ， 这 种 做 法 的 优点 是 可 以 极 大 地 降低 
管理 员 的 工作 量 。 想 象 一 个 为 数 百 个 用 户 提供 访问 的 系统 一 一 管理 所 有 这 些 人 本 身 就 是 
一 项 庞大 的 工作 ， 因 此 管理 员 可 以 找 一 些 人 自行 管理 数据 的 一 个 子 集 。 


8.1.7 ”处 理 列 级 安全 性 


在 某 些 情况 下 ， 并 非 所 有 人 都 被 允许 看 见 所 有 的 数据 。 想 象 一 家 银行 ， 某 些 人 可 以 
看 到 有 关 一 个 银行 账户 的 全 部 信息 ， 而 其 他 人 可 能 只 能 看 到 数据 的 一 个 子 集 。 在 真实 世 
界 的 情况 中 ， 某 人 可 能 被 允许 读 取 余额 列 或 者 默认 可 能 看 不 到 人 们 贷款 的 利率 。 另 一 个 
例子 是 人 们 被 允许 查看 人 员 的 概要 信息 但 看 不 到 他 们 的 照片 或 某 些 其 他 隐私 信息 。 现 在 
的 问题 是 ， 怎样 使 用 列 级 安全 性 ? 

为 了 展示 ， 笔 者 将 对 属于 joe 角色 的 已 有 表 增 加 一 列 : 

test=> ALTER TABLE t useful ADD COLUMN name text; 

ALTER TABLE 

现在 这 个 表 由 两 列 组 成 。 这 个 例子 的 目标 是 确保 一 个 用 户 只 能 看 到 其 中 一 列 : 


test=> \d t useful 
Table "public.t useful" 





























Column | Type | Modifiers 
ES Se 
id | integer | 

name | text 1 


让 我 们 创建 一 个 用 户 并 且 让 它 能 访问 包含 例子 表 的 方案 : 


test=# CREATE ROLE paul LOGIN; 

CREATE ROLE 

test=# GRANT CONNECT ON DATABASE test TO paul; 
GRANT 

test=# GRANT USAGE ON SCHEMA public TO paul; 
GRANT 


不 要 忘记 把 CONNECT 权利 给 予 新 人 ， 因 为 在 本 章 稍 早 的 地 方 ，CONNECT 已 经 被 
从 public 收回 。 因 此 为 了 确保 我 们 能 够 有 机 会 访问 该 表 ， 显 式 授权 是 绝对 必要 的 。 
可 以 把 SELECT 权限 给 paul 角色 : 


test=# GRANT SELECT (id) ON t useful TO paul; 
GRANT 
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基本 上 ， 这 已 经 足够 。 已 经 可 以 作为 用 户 paul 连接 到 数据 并 且 读 取 该 列 : 


[hs@zenbook ~]$ psql test -U paul 


test=> SELECT id FROM t useful; 
id 


(0 rows) 

如 果 使 用 列 级 权限 ， 有 一 件 重要 的 事情 需要 记 住 : 应 该 停止 使 用 SELECT *， 因 为 它 
已 经 无 法 再 用 : 

test=> SELECT * FROM t useful; 

ERROR: permission denied for relation t useful 

*# 仍 然 表 示 所 有 列 ， 但 由 于 这 里 没有 办 法 访问 所 有 列 ， 访 问 尝试 将 会 立即 导致 报错 。 

8.1.8 配置 默认 特权 


到 目前 为 止 ， 我 们 已 经 配置 了 很 多 东西 。 现 在 自然 而 然 会 产生 的 麻烦 是 ， 如 果 新 表 
被 加 入 系统 会 发 生 什么 ? 逐个 处 理 这 些 表 并 且 设 置 正 确 的 权限 可 能 会 非常 痛苦 并 且 有 风 
险 。 如 果 这 些 事情 自动 发 生 会 不 会 很 好 ? 这 就 是 ALTER DEFAULT PRIVILEGES 子 句 负 
责 的 事情 。 其 思想 是 给 用 户 一 种 选项 ， 它 能 让 PostgreSQL 在 对 象 一 出 现时 自动 设置 想 要 
的 权限 。 这 样 就 再 不 会 发 生 忘记 设置 那些 权限 的 情况 。 

下 面 的 列表 展示 了 该 语法 说 明 的 第 一 部 分 : 


test=# h ALTER DEFAULT PRIVILEGES 





Command: ALTER DEFAULT PRIVILEGES 
Description: define default access privileges 
Syntax: 


ALTER DEFAULT PRIVILEGES 
[ FOR { ROLE | USER } target role [, ...] ] 
[ IN SCHEMA schema name [, ...] ] 
abbreviated grant or revoke 


where abbreviated grant or revoke is one of: 


GRANT { { SELECT | INSERT | UPDATE | DELETE 


| TRUNCATE 
| REFERENCES | TRIGGER } 
[AU PRIVILEGES IT } 


ON TABLES 
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TO { [ GROUP ] role name | PUBLIC } [, ...] [ WITH GRANT OPTION ] 


基本 上 ， 该 语法 的 效果 类 似 于 GRANT 子 句 ， 因 此 比较 容易 和 直观 地 使 用 。 为 了 向 
读者 展示 如 何 使 用 它 ， 笔 者 编 了 一 个 简单 的 例子 。 其 想法 是 如 果 joe 角色 创建 一 个 表 ， 
paul 角色 将 自动 能 使 用 它 : 

test=# ALTER DEFAULT PRIVILEGES FOR ROLE joe 

IN SCHEMA public 

GRANT ALL ON TABLES TO paul; 
ALTER DEFAULT PRIVILEGES 
现在 作为 joe 角色 连接 并 且 创 建 一 个 表 : 


[hs@zenbook ~]$ psql test -U joe 





test=> CREATE TABLE t user (id serial, name text, passwd text); 
CREATE TABLE 


作为 paul 角色 连接 将 证 明 该 表 已 经 被 指派 了 正确 的 权限 集 : 


[hs@zenbook ~]$ psql test -U paul 


test=> SELECT * FROM t user; 
id | name | passwd 

ES 本 

(0 rows) 


8.2 深入 行 级 安全 性 一 一 RLS 


到 目前 为 止 ， 一 个 表 总 是 被 作为 整体 显示 。 当 表 包 含 一 百 万 行 时 ， 可 以 从 中 检索 一 
百 万 行 。 如 果 某 人 有 权利 读 取 一 个 表 ， 该 权利 就 是 有 关 整 个 表 的 。 在 很 多 情况 下 ， 这 就 
足够 了 。 但 实际 经 常会 想 让 一 个 用 户 不 能 看 到 所 有 行 。 

考虑 下 面 这 个 真实 世界 的 例子 ， 一 个 会 计 为 很 多 人 做 会 计 工作 。 该 表 包 含 应 该 对 所 
有 人 可 见 的 税率 ， 因 为 每 个 人 必须 支付 相同 的 税率 。 但 是 对 于 实际 的 交易 ， 用 户 可 能 
望 确保 每 个 人 只 被 允许 查看 他 或 者 她 自己 的 交易 。 

人 员 A 不 应 被 允许 看 到 人 员 B 的 数据 。 此 外 ， 可 能 还 有 必要 允许 一 个 部 门 的 老板 查 
看 公司 中 属于 他 这 一 部 分 的 数据 。 

行 级 安全 性 就 是 为 这 种 目的 设计 的 ， 它 允许 用 户 以 快速 简便 的 方式 构建 多 租户 系 
统 。 配 置 那些 权限 的 方法 是 使 用 策略 。 这 里 的 CREATE POLICY 命令 为 用 户 提 供 了 一 种 
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方式 来 编写 那些 规则 : 


test=# h CREATE POLICY 
Command: CREATE POLICY 
Description: define a new row level security policy for a table 
Syntax: 
CREATE POLICY name ON table name 
[ FOR { ALL | SELECT | INSERT | UPDATE | DELETE } ] 
[ TO { role name | PUBLIC | CURRENT USER | SESSION USER } [, ...] ] 
[ USING ( using expression ) ] 
[ WITH CHECK ( check expression ) ] 


为 了 向 读者 展示 如 何 编写 一 条 策略 ， 笔 者 首先 作为 超级 用 户 登录 并 且 创 建 一 个 包含 
若干 项 的 表 : 
test=# CREATE TABLE t person (gender text, name text); 
CREATE TABLE 
test=# INSERT INTO t person VALUES 
('male', 'joe'), ('male', 'paul'), ('female', 'sarah'), (NULL, 'R2- 
D2'); 
INSERT 0 4 


然后 为 joe 角色 的 访问 授权 : 


test=# GRANT ALL ON t person TO joe; 
GRANT 


到 目前 为 止 所 做 的 事情 都 很 普通 ， 并 且 joe 角色 将 能 够 实际 读 取 整 个 表 ， 因 为 RLS 
还 没有 就 位 。 但 是 如 果 为 该 表 启 用 行 级 安全 性 会 发 生 什么 ? 


test=# ALTER TABLE t person ENABLE ROW LEVEL SECURITY; 
ALTER TABLE 


默认 就 有 一 条 否决 全 部 的 策略 ， 因 此 joe 角色 实际 将 得 到 一 个 空 表 : 


test=> SELECT * FROM t person; 
gender | name 





Wh 





了 实 上 ， 这 条 默认 策略 很 有 意义 ， 因 为 用 户 会 被 强制 要 求 明确 地 设置 权限 。 
现在 这 个 表 已 经 处 于 行 级 安全 性 控制 之 下 ， 可 以 开始 编写 策略 了 【作为 超级 用 户 ) : 


























test=# CREATE POLICY joe pol 1 
ON t person 
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FOR SELECT TO joe 
USING (gender = "male'): 
CREATE POLICY 


作为 joe 角色 登录 并 且 选 择 所 有 数据 ， 将 只 会 返回 两 行 : 


test=> SELECT * FROM t person; 
gender | name 


male | joe 
male | paul 
(2 rows) 


让 我 们 以 更 细致 的 方式 观察 一 下 笔者 刚才 创建 的 策略 。 读 者 看 到 的 第 一 件 事 情 是 一 
条 策略 实际 是 有 名 字 的 。 它 还 被 连接 到 一 个 表 并 且 人 允许 特定 操作 〈 这 里 是 SELECT 子 
句 ) 。 然 后 就 是 USING 子 句 ， 它 基本 上 定义 了 joe 角色 将 被 允许 看 到 什么 。 因 此 USING 
子 句 是 附加 到 每 一 个 查询 的 一 种 强制 过 滤 ， 它 只 选择 用 户 被 假定 可 以 看 到 的 行 。 

现在 假定 由 于 某 种 原因 决定 也 允许 joe 角色 看 到 机 器 人 。 有 两 种 选项 可 以 实现 这 一 目 
的 。 第 一 种 选项 是 简单 地 使 用 ALTER POLICY 子 句 更 改 现 有 的 策略 : 


test=> h ALTER POLICY 


Command: ALTER POLICY 
Description: change the definition of a row level security policy 
Syntax: 


ALTER POLICY name ON table name RENAME TO new name 


ALTER POLICY name ON table name 
[ TO { role name | PUBLIC | CURRENT USER | SESSION USER } [, ...] ] 
[ USING ( using expression ) ] 
[ WITH CHECK ( check expression ) ] 


第 二 种 选项 是 如 下 例 所 示 创 建 第 二 条 策略 : 


test=# CREATE POLICY joe pol 2 
ON 七 person 
FOR SELECT TO joe 
USING (gender IS NULL) 
CREATE POLICY 


这 里 的 妙 处 是 那些 策略 会 被 使 用 OR 条 件 连接 起 来 。 因 此 ，PostgreSQL 现在 将 返回 
三 行 而 不 是 两 行 : 
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test=> SELECT * FROM t person; 


gender | name 


站 于 全 全 本 
male 1 joe 
male | paul 

| R2=D2 
(3 rows) 





R2-D2 角色 现在 也 被 包括 在 结果 中 ， 因 为 它 匹配 第 二 条 策略 。 
为 了 向 读者 展示 PostgreSQL 如 何 运行 该 查询 ， 笔 者 决定 把 该 查询 的 执行 计划 包括 进来 : 
test=> explain SELECT * FROM t person; 

QUERY PLAN 


Seq Scan on t person (cost=0.00..21.00 rows=9 width=64) 
Filter: ((gender IS NULL) OR (gender = 'male'::text)) 
(2 rows) 
如 你 所 见 ， 所 有 的 USING 子 句 都 会 被 作为 强制 过 滤 条 件 加 入 该 查询 中 。 
读者 可 能 已 经 注意 到 在 语法 定义 中 有 两 类 子 句 。 
@ USING: 这 个 子 句 过 滤 已 经 存在 的 行 。 它 与 SELECT 和 UPDATE 子 句 等 相关 。 
@ CHECK: 这 个 子 句 过 滤 将 要 被 创建 的 新 行 ， 因 此 它们 与 INSERT 和 UPDATE 子 
句 等 相关 。 
这 里 是 如 果 我 们 尝试 插入 一 行将 发 生 的 事情 : 
test=> INSERT INTO t person VALUES ('male', 'kaarel'); 
ERROR: new row violates row-level security policy for table "t person" 


因为 没有 针对 INSERT 子 句 的 策略 ， 该 语句 自然 会 报错 。 下 面 是 允许 插入 的 策略 : 


test=# CREATE POLICY joe pol 3 
ON t person 
FOR INSERT TO joe 
WITH CHECK (gender IN ('male', 'female')); 


CREATE POLICY 
如 下 面 的 列表 所 示 ，joe 角色 被 允许 向 表 中 增加 男性 和 女性 : 


test=> INSERT INTO t person VALUES ('female', maria'); 
INSERT 0 1 


不 过 ， 还 有 一 个 例外 ， 考 虑 下 面 的 例子 : 
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test=> INSERT INTO t _ person VALUES ('female', "maria'") RETURNING *; 
ERROR: new row violates row-level security policy for table "t person" 


回忆 一 下 ， 现 在 只 有 一 条 选择 男性 的 策略 。 这 里 的 麻烦 在 于 该 语句 将 返回 一 位 女 
这 是 不 被 允许 的 ， 因 为 joe 角色 受到 一 条 只 选择 男性 的 策略 约束 。 
RETURNING * 子 句 只 有 对 男性 才 会 实际 有 效 : 


test=> INSERT INTO t person VALUES ('male', "max'") RETURNING *; 
gender | name 








国 


INSERT 0 1 


如 果 用 户 不 想 要 这 种 行为 ， 必 须 编写 一 条 包含 正确 USING 子 句 的 策略 。 
83 检查 权限 


当 所 有 权限 被 设置 好 时 ， 有 时 候 有 必要 知道 谁 有 什么 权限 。 对 于 管理 员 来 说 找 出 谁 
被 允许 做 什么 是 至 关 重 要 的 。 不 幸 的 是 ， 这 一 过 程 并 不 容易 并 且 要 求 一 些 知识 。 通 常 ， 
笔者 是 一 个 命令 行 的 超级 粉丝 。 但 是 ， 在 查看 权限 系统 时 ， 实 在 有 必要 使 用 一 种 图 形 化 
用 户 接口 。 

在 向 读者 展示 如 何 读 取 PostgreSQL 权限 之 前 ， 笔 者 将 为 joe 角色 指派 权利 ， 这 样 可 
以 在 下 一 步 中 观察 : 

test=# GRANT ALL ON t person TO joe; 

GRANT 


检索 有 关 权限 的 信息 可 以 用 psql 中 的 z 命 令 完 成 : 


test=# x 
Expanded display is on. 





test=# z t person 
Access privileges 


RECORD 4======-===-==-=---=------=--=-=-=---==-===-====---=======-- 
Schema | public 

Name tperson 

Type | table 


Access privileges | postgres=arwdDxt/postgres 


6 


Column Privileges 


Policies 


平 


"female' : :text]) )+ 
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joe=arwdDxt/postgres 

joe pol 1 (r): 

(u) : (gender = 'male'::text) 

to: joe 

joe pol 2 (r): 

(u): (gender IS NULL) 

to: joe 

joe pol 3 (a): 

(c): (gender = ANY (ARRAY['male'::text, 


to: joe 


它 将 返回 所 有 那些 策略 以 及 有 关 Access privileges 的 信息 。 不 幸 的 是 ， 那 些 信息 不 容 
易 阅 读 并 且 笔 者 感觉 它们 并 没有 被 管理 员 们 广泛 地 理解 。 在 我 们 的 例子 中 ，joe 角色 从 
postgres 得 到 了 arwdDxt。 那 些 缩写 到 底 意味 着 什么 ? 
a: 追加 ， 用 于 INSERT 子 句 。 
r: 读 取 ， 用 于 SELECT 子 句 。 
w: 写 入 ,用 于 UPDATE 子 句 。 
: 删除 ， 用 于 DELETE 子 句 。 


: 被 用 于 引用 。 








t: 被 用 了 





触发 器 。 
如 果 用 户 不 了 解 那些 缩写 ， 还 有 第 二 种 方法 来 改善 可 读 性 。 考 虑 下 列 函 数 调用 : 


d 
D: 被 用 于 TRUNCATE 子 句 〈 当 它 被 引入 时 ，t 已 经 被 用 掉 了 ) 。 
这 














test=# SELECT * FROM aclexplode('{joe=arwdDxt/postgres}'); 


grantor grantee 

A 生生 过 
10 18481 
10 18481 
10 18481 
10 18481 





| privilege type | is grantable 
3 4 
| INSERT 车 

| SELECT 外 

| UPDATE ££ 

| DELETE | WE 
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10 1 18481 | TRUNCATE 本 

10 | 18481 | REFERENCES | 

EH 18481 | TRIGGER [| 夫 
(7 rows) 


如 你 所 见 ， 权 限 集合 被 作为 一 个 简单 表 返 回 ， 就 会 让 阅读 变 得 更 加 容易 。 
8.4 ”再 分 配对 象 和 删除 用 户 


在 指派 权限 和 限制 访问 之 后 ， 可 能 会 发 生 用 户 将 被 从 系统 中 删除 的 情况 。 不 出 所 
料 ， 做 这 件 事 的 命令 是 DROP ROLE 和 DROP USER: 


test=# h DROP ROLE 

Command: DROP ROLE 

Description: remove a database role 
Syntax: 

DROP ROLE [ IF EXISTS ] name [, ...] 


让 我 们 试 一 下 : 


test=# DROP ROLE joe; 

ERROR: role "joe" cannot be dropped because some objects 
depend on it 

DETAIL: target of policy joe pol 3 on table t person 

target of policy joe pol 2 on table t person 

target of policy joe pol 1 on table t person 

privileges for table t person 

owner of table t user 

owner of sequence t user id seq 

owner of default privileges on new relations belonging to role joe 
in schema public 

owner of table t useful 


PostgreSQL 会 发 出 错误 消息 ， 因 为 一 个 用 户 只 有 在 被 剥夺 了 所 有 东西 以 后 才能 被 移 
除 。 其 原因 是 ， 假 定 某 人 拥有 一 个 表 ，PostgreSQL 应 该 怎么 处 理 那 个 表 ? 必须 要 有 人 拥 
有 它们 。 为 了 把 表 从 一 个 用 户 重 新 分 配 到 下 一 个 用 户 ， 考 虑 一 下 REASSIGN 子 句 : 

test=# h REASSIGN 


Command: REASSIGN OWNED 
Description: change the ownership of database objects owned 














by a database role 
Syntax: 
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REASSIGN OWNED BY { old role | CURRENT USER | SESSION USER } [, ...] 
TO { new role | CURRENT USER | SESSION USER } 


该 语法 也 非常 简单 并 且 有 助 于 简化 这 种 交接 处 理 。 这 里 有 一 个 例子 : 
test=# REASSIGN OWNED BY joe TO postgres; 

REASSIGN OWNED 

为 此 让 我 们 再 次 尝试 删除 joe 角色 : 


test=# DROP ROLE joe; 

ERROR: role "joe" cannot be dropped because some objects depend on it 
DETAIL: target of policy joe pol 3 on table t person 

target of policy joe pol 2 on table t person 

target of policy joe pol 1 on table t person 














privileges for table t person 
owner of default privileges on new relations belonging to role joe 
in schema public 


如 你 所 见 ， 问 题 列 表 已 经 被 显著 地 缩短 。 现 在 我 们 能 够 做 的 是 逐个 解决 这 些 问题 并 
且 删 除 该 角色 。 笔 者 没有 发 现 有 捷径 可 走 ， 唯 一 可 以 让 这 种 处 理 更 加 有 效 的 方法 是 确保 
尽 可 能 少 地 直接 把 权限 分 配给 用 户 。 尽 量 尝试 用 角色 来 抽象 权限 ， 然 后 让 很 多 人 都 使 用 
角色 。 即 便 个 别 权限 被 直接 分 配给 用 户 ， 通 常事 情 也 会 比较 容易 处 理 。 





8.5 总 结 
数据 库 安全 性 是 一 个 非常 广 的 领域 ， 本 章 十 来 页 的 篇 幅 很 难 覆 盖 PostgreSQL 安全 性 
的 所 有 方面 。 很 多 诸如 SELinux、 安 全 性 定义 者 /调用 者 之 类 的 内 容 都 没有 被 触及 。 不 
过 ， 在 本 章 中 读者 学 到 了 作为 一 个 PostgreSQL 开发 者 和 DBA 将 会 面 对 的 最 常见 的 问 
题 。 读 者 学 到 了 如 何 避 免 基 本 的 陷阱 以 及 如 何 让 系统 更 加 安全 。 
在 第 9 章 中 ， 读 者 将 学 习 有 关 PostgreSQL 流 复制 和 增 量 备份 的 内 容 。 该 章 还 将 涵盖 
故障 转移 场景 的 相关 内 容 。 
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在 本 书 的 第 8 章 ， 笔 者 尝试 让 读者 了 解 了 以 最 简单 和 最 有 益 的 方法 保护 PostgreSQL 的 
相关 知识 。 本 章 的 主题 将 是 备份 和 恢复 。 执 行 备份 应 当 是 一 种 定期 任务 ， 并 且 每 一 个 管理 
员 都 应 该 关注 这 一 关键 性 的 活动 。 幸 运 的 是 ，PostgreSQL 提供 了 创建 备份 的 便利 方法 。 
本 章 将 涵盖 下 列 主题 : 
@ 运行 pg _ dump。 
部 分 转 储 数据 。 
还 原 备 份 。 
利用 并 行 性 。 
保存 全 局 数据 。 
在 本 章 结束 时 ， 读 者 将 能 够 设置 正确 的 备份 机 制 。 


9.1 执行 简单 转 储 


如 果 用 户 已 经 在 运行 一 个 PostgreSQL， 基 本 上 有 两 种 主要 的 方法 来 执行 备份 : 

@ ”逻辑 备份 (抽取 一 个 SQL 脚本 来 表示 数据 ) 。 

@ 事务 日 志 传 送 。 

事务 日 志 传 送 的 思想 是 归档 对 数据 库 的 二 进 制 改变 。 大 部 分 人 声称 事务 日 志 传 送 是 
执行 备份 的 唯一 方式 ， 但 在 笔者 看 来 并 不 一 定 是 那样 。 

很 多 人 依靠 pg_dump 简单 地 提取 数据 的 文本 表示 。pg_dump 也 是 最 古老 的 创建 备份 
的 方法 ， 并 且 从 PostgreSQL 项 目 开 始 至 今 都 在 被 使 用 (事务 日 志 传 送 很 久 以 后 才 被 加 
入 ) 。 每 一 个 PostgreSQL 管理 员 迟 早 将 接触 到 pg_dump， 因 此 有 必要 了 解 它 究竟 怎么 工 
作 以 及 它 能 做 些 什么 。 











9.1.1 运行 pg_dump 
我 们 想 要 做 的 第 一 件 事 是 创建 一 个 简单 的 文本 形式 的 转 储 : 
[hselinuxpc ~]$ pg dump test > /tmp/dump.sql 


这 是 能 想象 到 的 最 简单 的 备份 。pg_dump 登录 本 地 数据 库 实例 ， 连 接 到 数据 库 test 并 
且 开始 抽取 所 有 的 数据 ， 这 些 数据 将 被 发 送 到 stdout， 并 且 被 重 定向 到 文件 。 这 样 做 的 好 
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处 是 标准 输出 可 以 把 Unix 系统 的 所 有 灵活 性 都 发 挥 出 来 。 用 户 可 以 很 容易 地 使 用 一 个 管 
道 来 压缩 数据 或 者 做 任何 想 做 的 事情 。 

在 很 多 情况 下 ， 使 用 者 可 能 想 要 作为 一 个 不 同 的 用 户 运行 pg_dump。 所 有 PostgreSQL 
客户 端 程序 都 支持 一 套 一 致 的 命令 行 参数 来 传递 用 户 信息 。 如 果 想 要 设置 用 户 ， 可 以 使 
用 -U 标志 : 

[hselinuxpc ~]$ pg dump -U whatever _ powerful_ user test > /tmp/dump.sql 


下 列 参数 集合 可 以 在 所 有 PostgreSQL 客户 端 程序 中 找到 : 




















Connection options: 


-d, --dbname=DBNAME database to dump 

-h, --host=HOSTNAME database server host or 
socket directory 

-p, --port=PORT database server port number 

-U, --username=NAME connect as specified database user 

-Ww, --no-password never prompt for password 

-W, --password force password prompt (should 
happen automatically) 

—-role=ROLENAME do SET ROLE before dump 


只 要 把 想 要 的 信息 传递 给 pg_dump 并 且 具 有 足够 的 权限 ，PostgreSQL 将 会 取得 数 
据 。 这 里 的 重点 是 看 看 该 程序 实际 如 何 工作 。 简 单 来 说 ，pg_dump 会 连接 到 数据 库 并 且 
打开 一 个 大 型 的 可 重复 读 事务 ， 该 事务 会 简单 地 读 取 所 有 的 数据 。 记 住 ， 可 重复 读 确 保 
PostgreSQL 创建 数据 的 一 份 一 致 的 快照 ， 它 在 事务 中 至 始 至 终 都 不 会 改变 。 换 句 话 说 ， 
转 储 总 是 一 致 的 一 一 不 会 有 外 键 被 违背 。pg_dump 的 输出 是 转 储 开始 时 数据 的 一 份 快照 。 
这 里 一 致 性 是 一 个 关键 因素 ， 它 还 表示 转 储 运行 时 对 数据 的 更 改 将 不 会 出 现在 备份 中 。 
人 转 储 简单 地 读 取 所 有 东西 一 一 因此 ， 没 有 单独 的 转 储 权 限 ， 只 要 能 读 对 

象 ， 就 能 备份 它 。 

还 要 注意 备份 的 默认 格式 是 文本 格式 。 这 意味 着 可 以 安全 地 从 Solaris 抽取 的 数据 ， 
移动 到 某 种 其 他 CPU 架构 上 。 在 二 进 制备 份 的 情况 下 ， 这 显然 不 可 能 ， 因 为 磁盘 格式 依 
赖 于 CPU 架构 。 


9.1.2 ”传递 口令 和 连接 信息 
如 果 仔细 观察 9.1.1 节 中 展示 的 连接 参数 ， 读 者 将 会 注意 到 没有 办 法 向 pg_dump 传递 
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口令 。 用 户 可 以 使 用 口令 提示 来 要 求 口令 ， 但 是 没有 办 法 用 命令 行 选 项 把 口令 传递 给 
pg_dump。 其 原因 很 简单 : 口令 可 能 会 出 现在 进程 表 中 并 且 可 能 因此 对 其 他 人 可 见 ， 所 以 
不 能 支持 这 种 方式 。 现 在 的 问题 是 : 如 果 服 务 器 上 的 pg_hba.conf 强制 要 求 口令 ， 客 户 端 
程序 怎样 才能 提供 ? 

有 几 种 方式 可 以 做 到 : 

@ ”利用 环境 变量 。 

@ 利用 .pgpass。 

@ ”使 用 服务 文件 。 

在 本 节 中 ， 读 者 将 学 到 所 有 3 种 方法 。 


1， 使 用 环境 变量 


一 种 方法 是 使 用 环境 变量 传递 各 种 参数 。 如 果 信 息 没 有 被 明确 地 传递 给 pg_dump， 
它 将 在 预定 义 的 环境 变量 中 查找 缺少 的 信息 。 所 有 可 能 的 环境 变量 的 列表 可 以 在 下 面 的 
网 址 找到 :https:Wwww.postgresql.org/docs/9.6/static/libpq-envars.html。 

下 面 展 示 了 备份 通常 需要 的 一 些 环境 变量 。 

@ PGHOST: 告诉 系统 要 连接 哪 台 主机 。 

@ PGPORT: 定义 要 被 使 用 的 TCP 端口 。 

@ PGUSER: 告诉 客户 端 程序 要 使 用 的 用 户 。 

@ ”PGPASSWORD: 包含 要 使 用 的 口令 。 

@ PGDATABASE: 是 要 连接 的 数据 库 名 称 。 

使 用 这 些 环境 变量 的 好 处 是 口令 不 会 出 现在 进程 表 中 。 不 过 ， 还 不 仅 限于 此 ， 考 虑 
下 面 的 例子 : 


Boql ry ee sD Dd 


假定 读者 是 一 个 系统 管理 员 : 你 真 想 每 天 都 多 次 输入 这 么 长 的 行 吗 ? 如果 每 次 都 是 
用 相同 的 主机 ， 只 需要 设置 那些 环境 变量 并 且 用 psql 连接 就 行 ; 


[hs@linuxpc ~]$ export PGHOST=localhost 
[hs@linuxpc ~]$ export PGUSER=hs 
[hs@linuxpc ~]$ export PGPASSWORD=abc 
[hs@linuxpc ~]$ export PGPORT=5432 
[hs@linuxpc ~]$ export PGDATABASE=test 
[hselinuxpc ~]$ psql 

psql (9.6.1) 

Type "help" for help- 
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如 你 所 见 ， 这 里 不 再 有 命令 行 参 数 。 只 是 输入 psql 就 可 以 登入 。 


所 有 基于 标准 C 库 ( libpq ) 的 应 用 都 能 理解 那些 环境 变量 ， 因 此 可 以 把 它 
们 用 于 psql 和 pg _ dump 之 外 的 很 多 其 他 应 用 。 


2. 利用 .pgpass 

一 种 很 常见 的 存放 登录 信息 的 方法 是 使 用 .pgpass 文件 。 其 思想 很 简单 : 在 用 户 的 主 
目录 下 放 一 个 名 为 .pgpass 的 文件 ， 并 且 将 用 户 的 登录 信息 放 在 其 中 。 格 式 也 很 简单 ; 

hostname:port:database:username:password 

下 面 是 一 个 例子 : 

192.168.0.45:5432:mydb:xy:abc 

PostgreSQL 提供 了 一 种 很 好 的 额外 功能 : 大 部 分 域 都 可 以 包含 *。 例 如 : 

De 

这 意味 着 在 每 一 台 主机 上 、 在 每 个 端口 上 、 对 每 个 数据 库 ， 名 为 xy 的 用 户 都 将 使 用 
abc 作为 口令 。 要 让 PostgreSQL 使 用 .pgpass 文件 ， 确 保 设 置 好 正确 的 文件 权限 : 

chmod 0600 ~/.pgpass 


.pgpass 也 可 以 被 用 在 Windows 系统 上 。 在 这 种 情况 下 ， 该 文件 可 以 在 %APPDATA%A\ 
postgresql\pgpass.conf 路 径 上 找到 


3 使 用 服务 文件 


不 过 ， 还 不 只 可 以 使 用 .pgpass 文件 ， 用 户 还 可 以 利用 服务 文件 。 方 法 如 下 ， 如 果 用 
户 想 要 多 次 连接 到 相同 的 服务 器 ， 可 以 创建 一 个 .pg_service.conf 文件 ， 其 中 将 保存 所 有 需 
要 的 连接 信息 。 

这 里 是 一 个 .pg_service.conf 文件 的 例子 : 


Mac:~ hs$ cat .pg service.conf 


t 





# a sample service 
[hansservice] 
host=localhost 
port=5432 
dbname=test 
user=hs 
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password=abc 


[paulservicel] 

host=192.168.0.45 

port=5432 

dbname=xyz 

user=paul 

password=cde 

要 连接 到 其 中 一 个 服务 ， 只 需要 设置 环境 并 且 连 接 : 
iMac:~ hs$ export PGSERVICE=hansservice 
现在 可 以 无 须 向 psql 传递 口令 而 建立 连接 : 
iMac:~ hs$ psql 

psql (96:1) 

Type "help" for help. 

test=# 


或 者 ， 可 以 这 样 做 : 


psql service=hansservice 


9.1.3 ”提取 数据 的 子 集 


到 目前 为 止 ， 读 者 已 经 看 到 了 如 何 转 储 一 整个 数据 库 。 但 是 ， 用 户 可 能 并 不 希望 这 
样 做 。 在 很 多 情况 下 ， 用 户 可 能 只 是 想 抽 取 表 或 者 方案 的 一 个 子 集 。 

pg_dump 可 以 做 到 这 一 点 并 且 提 供 了 数 个 开关 。 

@ -a: 只 转 储 数据 而 不 转 储 数据 结构 。 

@  -S: 只 转 储 数据 结构 而 跳 过 数据 。 

@ -0n: 只 转 储 一 个 特定 的 方案 。 

@  -N: 转 储 所 有 东西 但 排除 特定 的 方案 。 

@ -ft 只 转 储 特定 的 表 。 

@  -T: 转 储 所 有 东西 但 排除 特定 的 表 〈 如 果 想 排除 日 志 表 等 就 会 用 到 ) 。 

部 分 转 储 有 助 于 大 幅度 提高 速度 。 


9.1.4 ”处 理 多 种 数据 格式 


到 目前 为 止 ,读者 已 经 看 到 pg_dump 可 以 被 用 来 创建 文本 文件 。 但 问题 是 文本 文件 
只 能 被 完全 重 放 ， 如 果 用 户 已 经 保存 了 一 个 完整 的 数据 库 ， 用 户 只 能 重 放 整 个 数据 库 。 























"234 。 由 浅 入 深 PostgreSQL 


在 很 多 情况 下 ， 这 并 非 用 户 想 要 的 。 因 此 ，PostgreSQL 还 有 一 些 额 外 的 格式 提供 更 多 的 
功能 。 
目前 ，PostgreSQL 支持 4 种 格式 : 


-F, -format=cldltlp output file format 





(custom, directory, tar, 
plain text (default)) 
读者 已 经 看 过 了 纯 文 本 格式 ， 它 就 是 普通 的 文本 。 此 外 ， 用 户 可 以 使 用 自 定义 格 
式 。 自 定义 格式 是 一 种 压缩 过 的 转 储 ， 其 中 包括 一 个 表 的 内 容 。 这 里 有 两 种 方法 创建 一 
个 自 定义 格式 的 转 储 : 
[hselinuxpc ~]$ pg dump -Fc test > /tmp/dump.fc 
hs@linuxpc ~]$ pg dump -Fc test -f /tmp/dump.fc 
除了 表 内 容 ， 压 缩 转 储 还 有 一 个 优点 : 它 更 小 。 经 验 是 一 个 自 定义 格式 的 转 储 大 约 
比 要 备份 的 数据 库 实例 小 90%。 当 然 ， 这 高 度 依赖 于 索引 的 数量 ， 但 对 于 很 多 数据 库 应 
用 来 说 这 一 估计 总 是 对 的 。 
一 旦 创建 了 备份 ， 就 可 以 观察 备份 文件 : 


[hs@linuxpc ~]$ pg_restore --list /tmp/dump.fc 

















;7 


; Archive created at 2017-01-04 15:44:56 CET 


7 dbname: test 
; TOC Entries: 18 
了 Compression: -1 


; Dump Version: 1.12-0 

a Format: CUSTOM 

日 Integer: 4 bytes 

7 Offset: 8 bytes 

; Dumped from database version: 9.6.1 
7 Dumped by pg dump version: 9.6.1 


; Selected TOC Entries: 

3103; 1262 16384 DATABASE - test hs 

3; 2615 2200 SCHEMA - public hs 

3104; 0 0 COMMENT - SCHEMA public hs 
1; 3079 13350 EXTENSION - plpgsql 
3105; 0 0 COMMENT - EXTENSION plpgsql 
187; 1259 16391 TABLE public t test hs 
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pg_restore --list 将 会 返回 该 备份 的 内 容 表 。 

使 用 自 定义 格式 已 经 是 一 种 很 好 的 想法 ， 因 为 备份 的 尺寸 将 会 缩小 。 但 是 ， 还 不 仅 
如 此 ，-Fd 命令 将 以 目录 格式 创建 备份 。 用 户 现在 得 到 一 个 包含 若干 文件 的 目录 而 不 是 单 
个 文件 : 


[hselinuxpc ~]$ mkdir /tmp/backup 
[hselinuxpc ~]$ pg dump -Fd test -f /tmp/backup/ 
[hselinuxpc ~]$ cd /tmp/backup/ 
[hs@linuxpc backup]$ 1s -lh 
total 86M 
-rwWw=rW-r==。 1 hs hs ‘85M Jan 4 15:54 3095.dat.gz 
= 工 W= 工 W=E== 1 hs hs 107 Jan 4 15:54 3096.dat gz 
=rW-IW=r==s 1 ha hs 740K Jan 4 15:54 3097.dat.gz 
4 
4 

















15:54 3098.dat.gz 
15:54 toc.dat 


WTW- T= hs hs 39 Jan 
YW=LW= = 1 hs ha dK Jarn 


目录 格式 的 一 个 优点 是 可 以 使 用 多 个 CPU 核 来 执行 备份 。 在 纯 文本 格式 或 自 定义 格 
式 的 情况 下 ，pg_dump 将 仅 使 用 一 个 进程 ， 而 目录 格式 改变 了 这 一 规则 。 下 面 的 例子 展 
示 了 用 户 如 何 能 告诉 pg_dump 使 用 4 个 核 (任务 〉: 


[hs@linuxpc backup]$ rm -rf * 
[hs@linuxpc backup]$ pg_ dump -Fd test -f /tmp/backup/ -j 4 


注意 在 数据 库 中 有 越 多 对 象 ， 就 会 有 越 大 的 潜在 提速 空间 。 
9.2 重 放 备份 





只 有 备份 是 无 意义 的 ， 备 份 存在 的 意义 就 是 为 了 有 朝 一 日 用 它 来 进行 重 放 。 幸 运 地 
是 ， 重 放 备 份 很 容易 。 如 果 已 经 创建 一 个 纯 文本 备份 ， 可 以 简单 地 拿 到 那个 SQL 文件 
且 执 行 它 : 

psql your db < your file.sql 


(人 纯 文 本 备份 就 是 一 个 包含 所 有 东西 的 文本 文件 。 用 户 总 是 可 以 简单 地 重 放 











县 








文本 交 件 。 
如 果 在 备份 时 使 用 了 自 定 义 格式 或 者 目录 格式 ， en pg_restore 来 重 放 备 
份 。pg_restore 允许 用 户 做 所 有 奇妙 的 事情 ， 例 如 只 重 放 一 个 数据 库 的 一 部 分 等 。 不 过 在 





大 部 分 情况 下 ， 用 户 将 会 简单 地 重 放 整 个 数据 库 。 二 笔者 将 创建 一 个 空 
数据 库 并 且 重 放 一 个 自 定义 格式 的 转 储 : 
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[hselinuxpc backup]$ createdb new db 

[hselinuxpc backup]$ pg_ restore -d new db -j 4 /tmp/dump.fc 

注意 ，pg_restore 将 把 数据 增加 到 一 个 现 有 的 数据 库 。 如 果 数 据 库 非 空 ，pg_restore 可 
能 会 出 错 但 是 仍 会 继续 。 

-j 再 一 次 被 用 来 使 用 多 个 进程 。 在 笔者 的 例子 中 ，4 个 核 被 用 来 重 放 数据 (这 只 对 重 
放 多 个 表 有 效 ) 。 





由 


人 如 果 使 用 目录 格式 ， 用 户 可 以 简单 地 传 入 目录 的 名 字 而 不 是 文件 的 名 字 。 
就 性 能 而 言 ， 如 果 处 理 的 是 少量 或 者 中 等 量 的 数据 ， 转 储 是 一 种 好 的 方案 。 它 有 两 
@ ”用 户 将 得 到 一 个 快照 ， 因 此 最 后 一 个 快照 之 后 的 所 有 东西 都 将 被 丢失 。 
@ ”从 零 重建 一 个 转 储 相 比 二 进 制备 份 来 说 更 慢 ， 因 为 所 有 的 索引 都 必须 被 重建 。 
因此 ， 我 们 将 在 第 10 章 中 介绍 二 进 制 备份 。 


9.3 处理 全 局 数据 





在 9.2 节 中 ， 读 者 已 经 学 到 了 pg_dump 和 pg restore， 它 们 两 个 是 创建 备份 时 的 关键 
程序 。 最 重要 的 是 ，pg_dump 创建 数据 库 转 储 一 一 它 工作 在 数据 库 级 别 上 。 如 果 想 要 备 
份 整个 实例 ， 必 须 使 用 pg_dumpall 或 者 单独 转 储 所 有 数据 库 。 在 进一步 深入 之 前 ， 有 必 
要 看 看 pg_dumpall 如 何 工作 : 


pg_dumpall > /tmp/all.sql 


pg_dumpall 将 逐个 连接 到 数据 库 并 且 把 备份 结果 发 送 到 标准 输出 ， 这 里 可 以 用 Unix 
处 理 输出 。pg_dumpall 可 以 像 pg_dump 一 样 被 使 用 。 不 过 ， 它 有 一 些 缺点 。 它 不 支持 自 
定义 或 者 目录 格式 ， 因 此 不 能 提供 多 核 支持 一 一 用 户 将 受制 于 单线 程 。 

不 过 ，pg_dumpall 也 不 是 只 有 缺点 。 记 住 用 户 是 存在 于 实例 级 别 上 。 如 果 用 户 创建 
一 个 普通 的 数据 库 转 储 ， 用 户 将 得 到 所 有 的 权限 但 不 会 得 到 所 有 的 CREATE USER 语 
句 。 那 些 全 局 数据 不 会 被 包括 在 普通 转 储 中 一 一 它们 只 会 被 pg_dumpall 抽取 出 来 。 

如 果 用 户 只 想 要 全 局 数据 ， 用 户 可 以 使 用 -g 选项 运行 pg_dumpall: 


pg_dumpall -g > /tmp/globals.sql 


在 大 部 分 情况 下 ， 用 户 可 能 想 要 运行 “pg_dumpall -g” 以 及 自 定义 或 目录 格式 转 储 
来 抽取 其 实例 。 一 个 简单 的 备份 脚本 看 起 来 像 这 样 : 
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#!/bin/sh 
BACKUP DIR=/tmp/ 
pg dumpall -g > $BACKUP DIR/globals.sql 


for x in $(psql -c "SELECT datname FROM pg database 
WHERE datname NOT IN ('postgres', 'template0', 'templatel')" 
postgres -A -t) 
do 
pg_dump -Fc $x > $BACKUP DIR/$x.fc 
done 
它 将 首先 转 储 全 局 数据 ， 然 后 在 一 个 数据 库 列表 上 循环 将 它们 逐个 抽取 为 自 定义 
格式 。 


在 本 章 中 ， 读 者 从 大 体 上 学 到 了 创建 备份 和 转 储 。 到 目前 为 止 ， 二 进 制 备份 还 没有 被 
涉及 ， 但 读者 已 经 能 够 从 服务 器 抽取 文本 备份 以 便 以 最 简单 的 方式 保存 和 重 放 其 数据 。 

第 10 章 将 涉及 事务 日 志 传 送 、 流 复制 以 及 二 进 制备 份 。 读 者 将 学 到 如 何 使 用 
PostgreSQL 自 带 的 工具 来 复制 实例 。 





第 10 章 理解 备份 和 复制 





在 本 书 的 第 9 章 中 ， 读 者 学 到 了 很 多 有 关 备 份 和 恢复 的 内 容 ， 这 些 知 识 对 于 管理 来 
说 非常 重要 。 到 目前 ， 本 书 只 涉及 了 逻辑 备份 ， 笔 者 将 在 本 章 中 改变 这 一 点 。 

本 章 的 内 容 全 都 与 PostgreSQL 的 事务 日 志 有 关 ， 用 户 可 以 用 它 来 改进 设置 并 且 让 系 
统 更 加 安全 。 

本 章 将 覆盖 下 列 主 题 : 

@ 事务 日 志 可 以 做 什么 以 及 为 何 需 要 它 。 
执行 时 间 点 恢复 。 
设置 流 复制 。 
复制 冲突 。 
监控 复制 。 
同步 复制 vs. 异步 复制 。 
理解 时 间 线 。 

在 本 章 结束 时 ， 读 者 将 能 够 设置 事务 日 志 归 档 和 复制 。 但 要 记 住 这 一 点 : 本 章 绝对 
不 是 一 份 复制 特性 的 全 面 指南 ， 它 只 算是 一 份 简介 而 已 。 完 全 覆盖 复制 这 一 主题 可 能 需 
要 大 约 500 页 的 篇 幅 。 作 为 对 比 ，Packt 单独 出 版 的 《PostgreSQL Replication》 一 书 就 接 
近 400 页 。 

本 章 将 以 更 紧凑 的 形式 覆盖 最 基本 的 内 容 。 


10.1 理解 事务 日 志 


每 一 种 现代 数据 库 系 统 都 提供 功能 来 确保 系统 能 够 从 崩溃 假如 某 物 出 问题 或 者 某 
人 拔 掉 了 插头 ) 中 幸免 ， 而 且 对 于 文件 系统 和 数据 库 系统 都 应 能 得 到 这 样 的 保证 。 

PostgreSQL 还 提供 了 一 种 方法 确保 骨 溃 不 会 损伤 数据 完整 性 或 者 数据 本 身 。 它 能 保 
FE 在 电源 被 切断 的 情况 下 ， 系 统 将 总 是 能 够 重新 回 到 正常 状态 并 且 做 自己 的 工作 。 

提供 这 种 安全 性 的 方法 被 称 为 预 写 式 日 志 (WAL) 或 者 xlog。 其 思想 是 不 直接 写 入 
数据 文件 ， 而 是 先 写 入 日 志 。 为 什么 要 这 样 做 呢 ? 想象 一 下 用 户 正 在 写 某 些 数据 : 


INSERT INTO data ... VALUES ('12345678"'); 


假定 数据 被 直接 写 入 数据 文件 。 如 果 操 作 在 中 间 某 处 失败 ， 数 据 文 件 将 会 被 损坏 。 








已 了 
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它 可 能 会 包含 写 入 了 一 半 的 行 、 没 有 索引 指针 的 列 、 缺 少 提交 信息 等 。 由 于 硬件 并 不 能 


真正 保障 大 块 数据 的 原子 写 ， 必 须 找 到 一 种 方法 来 让 写 入 更 加 鲁 棒 。 通 过 写 入 日 





是 直接 写 入 文件 就 能 解决 这 一 问题 。 


个 在 PostgreSQL 中 ， 事 务 日 志 由 记录 构成 。 





志 而 不 


单 次 的 写 操作 可 能 由 数 个 日 志 记 录 组 成 ， 它 们 都 有 校 验 码 并 且 被 链接 在 一 起 。 单 个 
事务 可 能 包含 B- 树 、 存 储 管理 器 、 提 交 记 录 以 及 更 多 种 类 的 记录 。 每 一 类 对 象 都 有 自己 
的 WAL 项 并 且 确 保 该 对 象 能 够 在 衣 溃 时 幸免 。 如 果 出 现 骨 省 ，PostgreSQL 启动 时 将 基于 
事务 日 志 修复 数据 文件 以 确保 不 会 有 永久 性 损伤 发 生 。 





10.1.1 察看 事务 日 志 


在 PostgreSQL 中 ，WAL 通常 可 以 在 data 目录 〈 除 非 在 initdb 时 指定 其 他 目录 ) 的 


pg_xlog 目录 中 找到 。 下 面 是 其 形式 : 


[postgres@zenbook pg_xlog]$ pwd 
/var/lib/pgsql/9.6/data/pg_xlog 
[postgres@zenbook pg xlog]$ 1s -1 

total 688132 

= . 1 postgres postgres 16777216 
0000000100000000000000CD 

= 和 E 匀 ====== 二 . 1 postgres postgres 16777216 
0000000100000000000000CE 

到 下 全 一 一下 二 二 一 . 1 postgres postgres 16777216 
0000000100000000000000CF 

二 下 而 三 二 一 一 二 一 一 . 1 postgres postgres 16777216 
0000000100000000000000D0 

人 . 1 postgres postgres 16777216 
0000000100000000000000D1 

=EW= ====—= . 1 postgres postgres 16777216 
0000000100000000000000D2 





Jan 


Jan 


Jan 


Jan 


Jan 


Jan 


| 


13 


3 


下 3 


3 


好 


加 外 


7s 


证 


LTs 


58 


04 


04 


04 


04 


3 0d 


在 其 中 可 以 看 到 事务 日 志 总 是 16MB 的 文件 ， 名 称 由 24 个 数字 构成 。 文 件 名 的 编号 

是 十 六 进 制 ， 如 你 所 见 ，CF 后 面 就 是 D0。 文 件 总 是 固定 尺寸 。 

分 在 PostgreSQL 中 ， 事 务 日 志文 件 的 数量 与 事务 的 尺寸 无 关 。 我 们 可 以 用 很 
小 的 事务 日 志文 件 集 合 轻易 地 运行 数 TB 的 事务 。 
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10.1.2 理解 检查 点 


正如 笔者 前 面 已 经 提 到 的 ， 每 一 次 更 改 都 被 以 二 进 制 格式 〈 不 包含 SQL ) 写 入 
WAL。 这 会 导致 一 个 问题 : 数据 库 服 务 器 无 法 永远 保持 对 WAL 的 写 入 ， 因 为 随 着 时 间 
流逝 它 会 消耗 越 来 越 多 的 空间 。 因 此 在 某 个 时 间 点 事务 日 志 必须 被 重复 利用 ， 这 个 时 间 
点 由 后 台 自 动 发 生 的 检查 点 〈checkpoint) 确定 。 其 思想 如 下 : 当 数 据 被 写 入 时 ， 它 首先 
进入 事务 日 志 ， 然 后 脏 缓冲 区 被 放 入 共享 缓冲 区 中 。 那 些 脏 缓冲 区 必须 进入 磁盘 并 且 会 
被 后 台 写 入 器 或 者 检查 点 写 出 到 数据 文件 中 。 只 要 到 目前 为 止 的 所 有 脏 缓冲 区 都 已 经 被 
写 出 ， 事 务 日 志 就 能 被 删除 。 

绝对 不 要 手工 删除 事务 日 志文 件 。 如 果 那 样 做 了 ， 在 出 现 崩 溃 事 件 时 ， 数 
据 库 服务 器 将 不 能 重新 启动 ， 并 且 被 删除 的 日 志文 件 的 磁盘 空间 将 被 回收 用 于 
新 进入 的 事务 。 一 定 不 要 手工 去 触 碰 事务 日 志 ，PostgreSQL 会 自行 照顾 好 它 
们 ， 人 工 对 它们 做 任何 事情 实际 上 都 是 有 害 的 。 









































10.1.3 ”优化 事务 日 志 


检查 点 会 自动 由 服务 器 触发 。 不 过 ， 有 一 些 配置 参数 的 设置 决定 何 时 发 动 检查 点 。 
postgresql.conf 文件 中 的 下 列 参数 负责 处 理 检查 点 : 
#checkpoint timeout = 5min # range 30s-1d 
#max wal size = 1GB 
#min wal size = 80MB 
有 两 种 原因 会 发 起 检查 点 ， 时 间 用 完 或 者 空间 用 完 。 两 次 检查 点 之 间 的 最 大 时 间 由 
checkpoint_timeout 变量 定义 。 为 存储 事务 日 志 提 供 的 空间 大 小 将 在 min_wal_size 和 
max_ wal size 变量 之 间 变 化 。PostgreSQL 将 以 一 种 方法 自动 地 触发 检查 点 ， 该 方法 会 让 
实际 需要 的 空间 位 于 上 述 的 两 个 变量 值 之 间 。 
Imax_wal size 变量 是 一 个 软 限制 ，PostgreSQL ( 在 重负 载 下 ) 可 以 临时 需 
要 更 多 一 点 空间 。 换 各 话说 ， 如 果 事 务 日 志 位 于 一 个 单独 的 磁盘 上 ， 有 必要 确 
保 实 际 有 更 多 的 一 点 空间 可 以 用 来 存储 WAL。 


用 户 在 PostgreSQL 9.6 和 10.0 中 如 何 调节 事务 日 志 ? 在 9.6 中 ， 已 经 对 后 台 写 入 器 和 
检查 点 机 制 做 出 了 一 些 改 变 。 在 更 老 的 版 本 中 ， 在 某 些 用 例 下 较 小 的 检查 点 距离 从 性 能 
的 角度 来 说 是 有 意义 的 。 在 9.6 及 其 后 的 版 本 中 ， 这 种 情况 已 经 大 有 改观 ， 较 大 的 检查 点 
距离 基本 上 总 是 最 有 利 的 ， 因 为 那样 有 很 多 优化 可 以 被 应 用 在 数据 库 和 OS 级 别 上 以 提高 
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速度 。 最 值得 一 提 的 优化 是 在 块 被 写 出 前 先 会 被 排序 ， 这 可 以 很 大 程度 上 降低 机 械 磁 盘 





的 随机 IO。 

不 仅 如 此 ， 大 的 检查 点 距离 实际 上 会 减少 被 创建 的 WAL 量 。 是 的 ， 就 是 这 样 一 一 较 
大 的 检查 点 距离 导致 较 少 的 WAL。 

其 原因 很 简单 。 只 要 一 个 块 在 一 个 检查 点 后 第 一 次 被 修改 ， 它 就 会 被 完全 发 送 到 








WAL。 如 果 这 个 块 经 常 被 更 改 ， 只 有 更 改 会 被 放 入 日 志 中 。 较 大 的 距离 说 穿 了 会 导致 较 
少 的 全 页 写 ， 这 进而 会 减少 起 初创 建 的 WAL 量 。 如 笔者 的 一 篇 博文 中 所 述 ， 区 别 可 能 会 
非常 大 : http://www.cybertec.at/checkpoint-distance-and-amount-of-wal/。 

不 仅 如 此 ，PostgreSQL 还 允许 我 们 配置 检查 点 应 该 是 短暂 而 猛烈 还 是 应 该 散布 在 一 
段 较 长 的 时 间 段 上 。 默 认 值 是 0.5， 这 表示 检查 点 处 理应 该 在 当前 检查 点 和 下 一 个 检查 点 
的 正中 间 就 能 够 完成 : 

#checkpoint completion target = 0.5 


增 大 这 个 值 基本 上 表示 检查 点 被 拉 长 并 且 不 那么 猛烈 。 在 很 多 情况 下 已 经 证 实 ， 较 
大 的 值 有 利于 拉平 因为 猛烈 执行 检查 点 导致 的 VO 激增。 


10.2 事务 日 志 归 档 和 恢复 


在 对 事务 日 志 简单 介绍 之 后 ， 现 在 让 我 们 把 注意 力 放 在 事务 日 志 归 档 处 理 上 。 如 你 
所 见 ， 事 务 日 志 包 含 对 存储 系统 所 做 的 二 进 制 更 改 的 序列 。 因 此 ， 为 什么 不 用 它 来 复制 
数据 库 实例 并 且 做 很 多 其 他 很 酷 的 事情 呢 ? 


10.2.1 为 归档 进行 配置 


我 们 想 在 本 章 中 实现 的 第 一 件 事情 是 创建 一 个 配置 来 执行 标准 的 时 间 点 恢复 
(PITR) 。PITR 相 比 普通 转 储 有 若干 优势 : 

@ ”将 丢失 较 少 的 数据 ， 因 为 可 以 恢复 一 个 特定 的 时 间 点 而 不 只 是 固定 的 备份 点 。 

@ 恢复 将 会 更 快 ， 因 为 索引 不 需要 从 头 创 建 。 它 们 只 是 被 复制 过 来 就 可 以 投入 























使 用 。 
PITR 的 配置 很 容易 ， 只 需要 在 postgresql.conf 文件 中 做 少量 设置 : 
wal level = replica # used to be "hot standby" in older versions 
max wal senders = 5 # at least 2, better at least 2 


wal level 变量 说 明 服 务 器 被 假定 为 产生 足够 多 的 事务 日 志 以 允许 PITR。 如 果 
wal level 变量 被 设置 为 minimal (直到 PostgreSQL 9.6 都 是 默认 值 ) ， 事 务 日 志 将 只 包含 
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恢复 单 节 点 设置 所 需 的 信息 一 一 这 些 信 息 不 足以 处 理 复制 。 从 最 新 的 补丁 看 来 ， 在 
PostgreSQL 10.0 中 那些 默认 值 都 已 经 被 更 改 ， 因 此 设置 归档 甚至 会 更 加 容易 。 

max_wal_senders 变量 将 允许 我 们 从 服务 器 流 式 传送 WAL。 它 将 允许 用 户 使 用 
pg_basebackup 而 不 是 传统 基于 文件 的 备份 来 创建 一 个 初始 备份 ， 其 优势 是 pg_basebackup 
更 加 容易 使 用 。 

WAL 流 的 思想 是 把 创建 的 事务 日 志 复 制 到 某 个 可 以 安全 恢复 它 的 地 方 。 基 本 上 ， 有 
两 种 方法 来 传送 WAL: 

@ 使 用 pg_ receivexlog。 

@ ”使 用 文件 系统 方式 归档 。 

在 本 节 中 ， 读 者 将 看 到 如 何 设置 第 二 种 选项 。 在 普通 操作 期 间 ，PostgreSQL 保持 对 
那些 WAL 文件 的 写 入 。 当 postgresql.conf 文件 中 archive mode = on 时 ，PostgreSQL 将 为 
每 一 个 文件 调用 archive_command 变量 。 

其 配置 可 能 看 起 来 是 这 样 一 一 首先 ， 可 以 创建 一 个 存储 那些 事务 日 志文 件 的 目录 : 

mkdir /archive 

chown postgres.postgres archive 


下 面 的 项 可 以 在 postgresql.conf 文 件 中 更 改 : 


archive mode = on 
archive command = 'cp sp /archive/%f" 


重启 后 将 启用 归档 ， 但 让 我 们 先 配 置 pg_hba.conf 文 件 以 最 小 化 停机 时 间 。 

注意 用 户 可 以 把 任何 命令 放 入 archive_command 变量 中 。 很 多 人 使 用 rsync、scp 等 把 
他 们 的 WAL 文件 传送 到 安全 的 位 置 。 如 果 用 户 的 脚本 返回 0，PostgreSQL 将 假定 该 文件 
已 经 被 归档 。 如 果 返 回 其 他 任何 值 ，PostgreSQL 将 尝试 重新 归档 该 文件 。 这 是 必要 的 ， 
因为 数据 库 引 擎 必须 确保 没有 文件 被 丢失 。 如 要 执行 恢复 处 理 ， 就 不 允许 失去 任何 一 个 
文件 。 


10.2.2 配置 pg_hba.conf 文件 


现在 postgresql.conf 文件 已 经 被 成 功 地 配置 好 ， 接 着 需要 为 流 复制 配置 pg_hba.conf 
文件 。 注 意 ， 只 有 计划 使 用 pg_basebackup 才 有 必要 这 样 做 ， 它 是 当前 最 好 的 基础 备份 创 
建 工具 。 

基本 上 ，pg hba.conf 文件 中 的 选项 和 已 经 在 第 8 章 中 见 过 的 一 样 。 只 有 一 点 需要 记 住 ; 


# Allow replication connections from localhost, by a user with the 





# replication privilege. 
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local replication postgres trust 
host replication postgres L270 00532 trust 
host replication postgres =/128 trust 


用 户 可 以 定义 标准 的 pg_hba.conf 文件 规则 ， 重 点 是 第 二 列 提 到 了 replication。 普 通 
规则 是 不 够 的 一 一 确实 有 必要 增加 明确 的 复制 权限 。 还 要 记 住 不 需要 作为 一 个 超级 用 户 
来 执行 复制 ， 可 以 创建 一 个 特定 的 只 被 允许 登录 和 复制 的 用 户 。 

现在 pg_hba.conf 文 件 已 经 被 正确 地 配置 ，PostgreSQL 可 以 被 重启 了 。 


10.2.3 创建 基础 备份 


在 告诉 了 PostgreSQL 要 归档 WAL 文件 之 后 ， 现 在 是 时 候 创 建 第 一 个 备份 了 。 其 思 
想 是 得 到 一 个 备份 并 且 基 于 这 个 备份 重 放 WAL 文件 以 达到 任意 时 间 点 。 

要 创建 初始 备份 ， 用 户 可 以 求助 于 pg_basebackup， 它 是 一 个 用 来 执行 备份 的 命令 行 
工具 。 让 我 们 调用 pg_basebackup 并 且 看 看 它 如 何 工作 : 


pg_basebackup -D /some target dir 





-h localhost 
--checkpoint=fast 
--xlog-method=stream 


如 你 所 见 ， 笔 者 这 里 使 用 了 4 个 参数 。 


-D: 用 户 想 让 这 个 基础 备份 放 在 哪里 ? PostgreSQL 要 求 一 个 空 目 录 ， 在 备份 结 
束 时 ， 用 户 将 在 这 里 〈 目 标 ) 看 到 服务 器 数据 目录 的 一 份 备份 。 

-h: 指示 主 服务 器 (来 源 ) 的 他 地 址 或 者 名 称 。 这 是 想 要 备份 的 服务 器 。 
--checkpoint=fast: 通常 pg_basebackup 会 等 待 主 服务 器 到 检查 点 。 其 原因 是 重 放 
处 理 必须 从 某 处 开始 ， 而 一 个 检查 点 能 保证 到 某 个 特定 点 的 数据 都 已 经 被 写 
入 ， 因 此 PostgreSQL 能 够 安全 地 跳 到 那里 并 且 开 始 重 放 处 理 。 说 穿 了 ， 也 可 以 
不 用 --checkpoint=fast 参数 。 但 是 ， 那 种 情况 下 pg_basebackup 可 能 会 花 一 些 时 间 
才 开 始 复制 数据 。 检 查 点 可 能 会 相距 一 小 时 ， 这 可 能 会 不 必要 地 延迟 备份 。 
--Xlog-method=stream: 默认 情况 下 ，pg _basebackup 连接 到 主 服务 器 并 且 开 始 复 
制 文件 过 来 。 现 在 ， 要 记 住 那些 文件 在 被 复制 时 还 会 被 修改 ， 因 此 到 达 备 份 中 
的 数据 是 不 一 致 的 。 这 种 不 一 致 性 可 以 在 恢复 处 理 期 间 使 用 WAL 修复 。 不 过 ， 
备份 本 身 确实 是 不 一 致 的 。 通 过 增加 --xlogmethod=stream 参数 ， 就 可 以 创建 一 个 
自 包 含 的 备份 。 它 可 以 被 直接 启动 而 无 须 重 放 事 务 日 志 〈 如 果 只 是 想 克 隆 一 个 
实例 且 不 使 用 PITR， 这 种 方法 就 很 不 错 ) 。 
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1， 限 制备 份 的 带宽 


当 pg_basebackup 开始 时 ， 它 会 尝试 尽快 完成 其 工作 。 如 果 用 户 有 一 个 好 的 网 络 连 
接 ，pg_basebackup 无 疑 可 以 从 远程 服务 器 每 秒 取得 数 百 兆 字 节 。 如 果 用 户 服务 器 的 IO 
系统 较 弱 ， 这 就 意味 着 pg_basebackup 可 能 会 很 容易 地 吃 掉 所 有 的 资源 ， 最 终 用 户 可 能 会 
体验 到 不 好 的 性 能 ， 因 为 他 们 的 IO 请 求 太 慢 。 

为 了 控制 最 大 传输 率 ，pg_basebackup 提供 了 下 面 的 选项 : 


-r, --max-rate=RATE maximum transfer rate to transfer data directory 





(in kB/s, or use suffix "“k" or "M") 

在 创建 基础 备份 时 ， 要 确保 主 服务 器 上 的 磁盘 系统 实际 能 够 承受 这 种 负载 。 因 此 ， 
调整 传输 率 就 变 得 很 有 意义 了 。 

2， 了 映射 表 空 间 

如 果 在 目标 系统 上 使 用 的 是 相同 的 文件 系统 布局 ， 那 么 可 以 直接 调用 pg_basebackup。 
如 果 不 是 这 样 ，pg_basebackup 允许 把 主 服务 器 文件 系统 布局 映射 为 想 要 的 布局 : 


-T，--tablespace-mapping=OLDDIR=NEWDIR 
relocate tablespace in OLDDIR to NEWDIR 














és 如 果 系 统 很 小 ， 把 所 有 东西 都 放 在 一 个 表 空间 中 是 不 错 的 做 法 。 


只 要 LO 不 是 问题 (可 能 因为 只 需要 管理 若干 GB 的 数据 ) 都 可 以 这 样 做 。 
3 使 用 不 同 的 格式 


pg_basebackup 可 以 创建 多 种 格式 。 默 认 情况 下 ， 它 将 把 数据 放 在 一 个 空 目 录 中 。 本 
质 上 ， 它 将 连接 到 源 服 务 器 然后 在 网 络 连 接 上 执行 tar， 并 且 把 数据 放 到 想 要 的 目录 中 。 

这 种 方法 的 问题 是 pg_basebackup 将 创建 很 多 文件 ， 如 果 想 要 把 这 种 备份 移动 到 一 种 
外 部 备份 方案 (可 能 是 Tivoli 存储 管理 器 或 者 某 种 其 他 方案 ) 就 不 合适 : 

-F, 一 -Eormat=p| 七 output format (Plain (default), tar) 

要 创建 单个 文件 ， 可 以 使 用 “-EF=t” 选 项 。 默 认 情况 下 ， 它 将 创建 一 个 名 为 base.tar 
的 文件 ， 这 样 就 更 容易 管理 。 当 然 ， 缺 点 是 用 户 在 执行 PITR 之 前 必须 先 展开 该 文件 。 


4. 测试 事务 日 志 
在 我 们 深入 到 实际 的 重 放 处 理 之 前 ， 有 必要 检查 归档 以 确保 归档 能 正确 地 并 且 按 照 
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预期 工作 : 


[hs@zenbook archive]$ 1s -1 
total 212996 





NN 1 hs hs 16777216 Jan 30 09:04 000000010000000000000001 
= 六 证 == 二 二 = 二 = 二 1 hs hs 16777216 Jan 30 09:04 000000010000000000000002 
EW 1 hs hs 302 Jan 30 09:04 

000000010000000000000002.00000028 .backup 

和 1 hs hs 16777216 Jan 30 09:20 000000010000000000000003 
= 1 hs hs 16777216 Jan 30 09:20 000000010000000000000004 
生 瑞 征 三 三 二 二 三 一 二 1 hs hs 16777216 Jan 30 09:20 000000010000000000000005 
一 TW- 一 -一 一 一 二 1 hs hs 16777216 Jan 30 09:20 000000010000000000000006 


只 要 在 数据 库 上 进行 重要 的 活动 ，WAL 文件 就 应 该 被 发 送 到 归档 。 
除了 检查 文件 之 外 ， 还 有 下 面 的 视图 可 用 : 


test=# d pg_stat archiver 
View "pg catalog.pg stat archiver" 


Column 1 Type Modifiers 
archived count 


ast _ archived time | timestamp with time zone 


failed count bigint 
让 ex 
timestamp with time zone | 


ast_ failed wal 


1 
ast_archived wal | text 

1 

1 

1 

ast_failed time 1 

1 


stats_ reset 


当归 档 因为 某 种 原因 停 转 时 ，pg_stat_archiver 扩展 可 以 用 来 找 出 原因 。 它 将 告诉 用 户 
已 经 被 归档 的 文件 数量 〈archived_count) ， 用 户 也 能 看 到 哪个 文件 是 最 后 一 个 文件 以 及 它 
何 时 被 归档 。 最 后 ，pg_stat_archiver 扩展 可 以 告诉 用 户 归档 什么 时 候 发 生 错 误 ， 这 是 关键 
性 信息 。 不 幸 的 是 ， 错 误 代码 或 者 错误 消息 没有 被 显示 在 表 中 ， 但 由 于 archive_command 
可 以 是 任意 命令 ， 错 误 信 息 很 容易 记录 下 来 。 

在 归档 中 其 实 还 有 更 多 东西 ， 如 上 所 述 ， 有 必要 看 看 哪些 文件 已 经 实际 被 归档 。 但 
还 不 只 如 此 ， 当 pg _ basebackup 扩展 被 调用 时 ， 用 户 将 在 WAL 文件 流 中 看 到 一 个 .backup 
文件 。 这 个 文件 很 小 并 且 只 包含 有 关 基 础 备份 本 身 的 一 些 信息 一 一 它 纯粹 就 是 一 种 告知 
性 文件 ， 在 重 放 处 理 中 并 不 需要 它 。 但 是 ， 这 种 文件 给 出 了 一 些 至 关 重 要 的 线索 。 当 用 
户 后 来 开始 重 放 事 务 日 志 时 ， 用 户 可 以 删除 所 有 比 .backup 文件 老 的 WAL 文件 。 在 这 个 
案例 中 ， 我 们 的 备份 文件 是 000000010000000000000002.00000028.backup。 这 表示 重 放 处 


timestamp with time zone | 
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理会 从 文件 .0002 中 的 某 处 〈 位 置 ..28) 开始 ， 它 还 表示 我 们 可 以 删除 所 有 比 .…0002 老 的 
文件 ， 恢 复 不 再 需要 更 旧 的 WAL 文件 。 记 住 用 户 可 以 保留 多 于 一 个 备份 ， 因 此 笔者 这 里 
只 会 提 到 当前 备份 。 

现在 归档 开始 工作 ， 我 们 可 以 把 注意 力 转向 重 放 处 理 。 


10.2.4” 重 放 事务 日 志 
让 我 们 总 结 一 下 到 目前 为 止 的 整个 过 程 。 我 们 已 经 调整 了 postgresql.conf 文件 


(wal level、max_wal senders 、archive mode 和 archive command) ， 并 且 我 们 已 经 在 
pg_hba.conf 文件 中 允许 了 pg_basebackup 扩展 ， 然 后 数据 库 已 经 被 重启 过 并 且 成 功 地 产生 
了 一 个 基础 备份 。 
记 住 基础 备份 可 以 在 数据 库 全 面 运转 时 发 生 一 一 只 需要 一 次 快速 的 重启 来 改变 
max_wal_sender 以 及 wal_level 变量 。 备 份 可 以 在 数据 库 正常 提供 服务 时 发 生 。 
现在 ， 在 系统 已 经 可 以 正确 工作 之 后 ， 可 能 会 面临 朋 溃 ， 并 且 希 望 从 中 恢复 过 来 。 
因此 ， 我 们 可 以 执行 PITR 以 恢复 尽 可 能 多 的 数据 。 我 们 要 做 的 第 一 件 事情 是 拿 到 基础 备 
份 并 且 把 它 放 在 想 要 的 位 置 。 
保存 旧 的 数据 库 集 簇 是 一 种 好 办 法 。 即 使 它 损坏 ， 你 的 PostgreSQL 支持 公 
€9 司 可 能 需要 它 来 追踪 崩溃 的 原因 。 在 让 一 切 恢复 正常 开始 运行 之 后 ， 还 是 可 以 
删除 它 。 


按照 前 面 给 定 的 文件 系统 布局 ， 用 户 可 能 想 要 这 样 做 : 
cd /some target dir 
cp -Rv * /data 
笔者 假定 用 户 的 新 数据 库 服 务 器 将 被 放 在 /data 目录 中 。 在 将 基础 备份 复制 过 去 之 
前 ， 要 确定 该 目录 为 空 。 
下 一 步 将 创建 一 个 名 为 recovery.conf 的 文件 。 它 将 包含 重 放 处 理 关 心 的 所 有 信息 ， 
例如 WAL 归档 的 位 置 、 想 要 达到 的 时 间 点 等 。 
在 PostgreSQL 10.0 中 ，recovery.conf 很 可 能 不 再 存在 。 那 些 设置 预计 被 转 
C3 移 到 postgresql.conf 文件 中 。 在 写作 本 章 时 ， 笔 者 还 没有 完全 确定 到 底 会 怎样 
处 理 。 





























下 面 是 一 个 recovery.conf 文件 的 例子 : 


restore command = 'cp /archive/%f %p" 
Lecovery target time = "2019=04=05 15:43:12™ 
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把 recovery.conf 文件 放 到 SPGDATA 目录 中 后 ， 用 户 可 以 简单 地 启动 其 服务 器 。 输 出 
能 像 这 样 : 

server starting 
LOG: database system was interrupted; last known up 

at 2017-01-30 09:04:07 CET 
LOG: starting point-in-time recovery to 2019-04-05 15:43:12+02 
LOG: restored log file "000000010000000000000002" from archive 
LOG: redo starts at 0/2000028 
LOG: consistent recovery state reached at 0/20000F8 
LOG: restored log file "000000010000000000000003" from archive 
LOG: restored log file "000000010000000000000004" from archive 
LOG: restored log file "000000010000000000000005" from archive 


LOG: restored log file "00000001000000000000000E" from archive 
cp: cannot stat '/archive/00000001000000000000000F': 
No such file or directory 
LOG: redo done at 0/E7BF710 
LOG: last completed transaction was at log time 
2017-01-30 09:20:47.249497+01 
LOG: restored log file "00000001000000000000000E" from archive 
cp: cannot stat '/archive/00000002.history': No such file or directory 
LOG: selected new timeline ID: 2 
cp: Ccannot stat '/archive/00000001.history': No such file or directory 
LOG: archive recovery complete 
LOG: MultiXact member wraparound protections are now enabled 
LOG: database system is ready to accept connections 
LOG: autovacuum launcher started 


在 服务 器 被 启动 时 ， 可 以 查找 若干 消息 来 确认 恢复 过 程 工作 正确 ， 第 一 个 是 consistent 
recovery state reached。 这 个 消息 意味 着 PostgreSQL 可 以 重 放 足够 多 的 事务 日 志 将 数据 库 
带 回 到 一 个 状态 ， 该 状态 会 让 数据 库 真正 可 用 。 

然后 PostgreSQL 将 逐个 复制 文件 并 且 重 放 它 们 。 不 过 ， 记 住 我 们 已 经 告诉 recovery.conf 
文件 把 我 们 一 路 带 到 2019 年 。 但 这 本 书写 作 于 2017 年 ， 显 然 没 有 足够 的 WAL 能 到 达 
2019 年 。 因 此 ， PostgreSQL 将 会 报错 并 且 告 诉 我 们 有 关 最 后 一 个 已 完成 事务 的 情况 。 
当然 这 只 是 一 个 例子 而 已 ， 现 实 世 界 中 的 例子 中 用 户 将 很 可 能 使 用 一 个 过 去 的 日 
期 ， 这 样 就 能 安全 地 用 它 来 恢复 。 但 是 ， 笔 者 想 要 表达 的 是 使 用 未 来 的 日 志 是 完全 可 行 
的 一 一 只 是 要 做 好 准备 面 对 将 会 发 生 的 错误 。 
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在 恢复 完成 后 ，recovery.conf 文件 将 被 重 命名 为 recovery.done， 这 样 用 户 可 以 看 到 在 
恢复 期 间 发 生 了 什么 。 所 有 的 数据 库 服务 器 进程 都 将 被 启动 并 且 运 行 ， 并 且 用 户 就 已 经 
可 以 使 用 数据 库 实例 了 

@ ”查找 正确 的 时 间 截 

到 目前 为 止 ， 笔 者 都 是 假定 用 户 已 经 知道 要 恢复 到 哪个 时 间 戳 或 者 用 户 只 是 想 
所 有 的 事务 日 志 以 尽 可 能 减少 数据 损失 。 但 是 ， 如 果 用 户 不 想 重 放 所 有 日 志 该 怎么 > 
如 果 用 户 不 知道 要 恢复 到 哪个 时 间 点 该 怎么 办 ? 在 日 常生 活 中 ， 这 实际 上 是 一 种 很 常见 
的 场景 。 一 个 开发 人 员 在 上 午 丢 失 了 一 些 数据 ， 现 在 想 让 一 切 都 回 到 正轨 。 但 问题 是 ， 
上 午 的 什么 时 候 ? 一 旦 恢复 结束 ， 就 不 能 很 容易 地 重新 开始 一 次 。 一 旦 恢复 完成 ， 系 统 
就 会 被 提升 。 而 一 旦 系统 被 提升 ， 用 户 就 无 法 继续 重 放 WAL。 

不 过 用 户 可 以 暂停 恢复 而 不 做 提升 ， 检 查 数 据 库 中 有 什么 ， 然 后 继续 。 

这 样 做 比较 容易 。 第 一 件 要 做 的 事情 是 保证 postgresql.conf 文件 中 hot_standby 变量 
被 设置 为 on。 这 会 让 数据 库 在 恢复 模式 中 也 可 读 ， 然 后 在 开始 重 放 处 理 之 前 还 需要 修改 
一 下 recovery.conf 文件 : 





上 








recovery target action = "pause' 


有 好 几 种 recovery_target_action 设置 。 如 果 使 用 的 是 pause，PostgreSQL 将 在 达到 想 
要 的 时 间 点 后 暂停 ， 让 用 户 有 机 会 检查 哪些 东西 已 经 被 重 放 。 这 时 用 户 可 以 调整 想 要 达 
到 的 时 间 ， 重 新 启动 并 且 重 试 重 放 。 此 外 ， 还 可 以 把 该 值 设 置 为 promote 或 者 
shutdown 。 

有 第 二 种 方法 可 以 暂停 事务 日 志 重 放 。 本 质 上 ， 它 也 能 在 执行 PITR 时 使 用 。 但 是 ， 
在 大 部 分 情况 下 它 被 用 于 流 复 制 。 在 WAL 重 放 期 间 可 以 使 用 下 面 的 功能 


postgres=# x 





Expanded display is on. 
postgres=# df *pause* 
List of functions 


-[ RECORD 1 ]--—-—-——- 二 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 
Schema | pg_catalog 

Name | pg_is xlog replay paused 
Result data type | boolean 

Argument data types | 

Type | normal 

-[ RECORD 2 ]--—-—-——-— 二 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 
Schema | pg_catalog 
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Name | pg_xlog replay pause 
Result data type | void 

Argument data types | 

Type | normal 


postgres=# df *resume* 
List of functions 


-[ RECORD 1 ]------- 二 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 
Schema | pg_catalog 

Name | pg_xlog replay resume 
Result data type | void 

Argument data types | 

Type | normal 


用 户 可 以 调用 “SELECT pg_xlog replay_pause();” 命 令 停 住 WAL 重 放 ， 直 到 调用 
“SELECT pg xlog replay resume0;” 命 令 再 继续 。 

其 想法 是 找 出 有 多 少 WAL 已 经 被 重 放 并 且 根 据 需 要 继续 重 放 。 但 是 ， 要 记 住 一 点 : 
一 旦 服务 器 被 提升 ， 如 果 不 做 一 些 预防 工作 ， 用 户 就 无 法 继续 重 放 WAL。 

如 你 所 见 ， 要 找 出 已 经 恢复 了 多 少 可 能 会 相当 琼 手 。 因 此 ，PostgreSQL 提供 了 一 些 
方法 来 协助 。 考 虑 下 面 的 实际 例子 ， 一 个 午夜 ， 用 户 正 在 运行 每 晚 都 会 进行 的 处 理 并 且 
结束 于 一 个 通常 无 法 知晓 的 时 间 点 ， 而 目标 是 正好 恢复 到 该 处 理 的 结束 点 。 那 么 问题 就 
来 了 : 如 何 知 晓 该 处 理 何 时 结束 ? 在 大 部 分 情况 下 ， 这 是 很 难 找 出 的 。 所 以 不 如 在 事务 
日 志 中 加 上 一 个 标记 : 


postgres=# SELECT pg create restore point('my daily process ended'); 





pg_create restore point 


1F/E574A7B8 

(1 row) 

如 果 用 户 的 处 理 在 一 结束 时 就 调用 这 个 SQL 语句 ， 就 可 以 使 用 事务 日 志 中 的 这 个 标 
签 来 正好 恢复 到 这 个 时 间 点 ， 只 需要 把 下 列 内 容 直接 加 到 recovery.conf 文件 中 : 

recovery target name = "my daily process_ended' 

使 用 这 个 设置 取代 recovery target time， 重 放 处 理 把 用 户 正好 带 回 该 操作 的 结束 点 。 
当然 ， 用 户 还 可 以 重 放 到 一 个 特定 的 事务 ID。 不 过 ， 在 实际 生活 中 已 经 证 明 这 很 难 
做 到 ， 因 为 管理 员 更 难 准确 地 知道 事务 ID， 因 此 这 种 做 法 没有 很 大 的 实用 价值 。 
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10.2.5 ”清理 事务 日 志 归 档 


到 目前 为 止 ， 数 据 已 经 被 不 停 地 写 入 归档 ， 但 却 没有 关注 对 归档 进行 清理 ， 以 便 在 
文件 系统 中 释放 一 些 空间 。PostgreSQL 无 法 为 用 户 做 这 件 工作 ， 因 为 它 不 知道 用 户 是 否 
还 会 再 次 使 用 这 些 归档 。 因 此 ， 用 户 需 要 负责 清理 事务 日 志 。 当 然 ， 用 户 也 可 以 使 用 一 
种 备份 工具 一 一 但 是 ， 有 必要 知道 PostgreSQL 不 会 为 用 户 执行 清理 。 

假定 我 们 想 要 清理 掉 旧 的 事务 日 志 ， 它 们 不 再 被 需要 。 用 户 可 能 想 要 保留 几 个 基础 
备份 ， 并 且 清 理 所 有 恢复 那些 备份 时 不 再 需要 的 事务 日 志 。 

在 这 种 情况 下 ，pg_archivecleanup 扩展 正 是 我 们 所 需要 的 。 用 户 可 以 简单 地 把 归档 目 
录 和 备份 文件 的 名 称 传递 给 pg_archivecleanup 扩展 ， 它 确保 把 文件 从 磁盘 上 移 除 。 使 用 
这 个 工具 可 以 省 很 多 事 ， 因 为 用 户 不 必 自 行 找 出 哪些 事务 日 志文 件 需 要 被 保留 。 该 扩展 
的 用 法 如 下 : 


[hsepgnode01 ~]$ pg _archivecleanup --help 














pg_archivecleanup removes older WAL files from PostgreSQL archives. 


Usage: 

pg_archivecleanup [OPTION]... ARCHIVELOCATION OLDESTKEPTWALFILE 
Options: 

sd generate debug output (verbose mode) 

an dry run, show the names of the files that 

would be removed 

-V, --version output version information, then exit 

-x EXT clean up files if they have this extension 

-?2, --help show this help, then exit 


For use as archive cleanup command in recovery.conf when standby mode = on: 


archive cleanup command = 'pg_archivecleanup 
[OPTION] . . 。 ARCHIVELOCATION Sr" 
e.g. 
archive cleanup command = 'pg archivecleanup 


/mnt/server/archiverdir Sr" 


Or for use as a standalone archive cleaner: 
Qe 
pg_archivecleanup /mnt/server/archiverdir 
000000010000000000000010.00000020.backup 
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该 工具 易于 使 用 ， 并 且 在 所 有 的 平台 上 都 可 用 。 
10.3 设置 异步 复制 


在 看 过 了 事务 日 志 归 档 和 PITR 之 后 ， 我 们 可 以 把 重心 放 在 如 今 PostgreSQL 世界 中 
一 种 被 广泛 使 用 的 特性 上 : 流 复制 。 流 复制 的 思想 非常 简单 : 在 一 个 初始 的 基础 备份 之 
后 ， 次 服务 器 可 以 连接 到 主 服务 器 并 且 实时 取得 事务 日 志 进 行 应 用 。 事 务 日 志 重 放 不 再 是 
一 个 单一 操作 ， 而 是 一 种 连续 处 理 ， 只 要 集群 还 存在 这 种 处 理 就 被 假定 会 持续 运行 下 去 。 


10.3.1 执行 基本 设置 


在 本 节 中 ， 读 者 将 学 到 如 何 快速 简单 地 设置 异步 复制 。 我 们 的 目标 是 设置 一 个 由 两 
个 节点 组 成 的 系统 。 

基本 上 ， 大 部 分 的 工作 已 经 在 设置 WAL 归档 时 完成 了 。 但 是 为 了 读者 容易 理解 ， 笔 
者 还 是 会 解释 整个 设置 过 程 ， 因 为 我 们 不 能 假定 WAL 传送 实际 已 经 被 按照 需要 设置 好 。 

第 一 件 事情 是 在 postgresqlLconf 文件 中 调整 下 列 参数 : 


wal_level = replica 


























max_wal_senders = 5 # or whatever value >= 2 
hot_standby = on # already a sophistication 


和 之 前 一 样 ，wal_level 变量 必须 调整 以 确保 PostgreSQL 产生 足够 的 事务 日 志 来 支撑 

- 台 从 服务 器 ， 然 后 必须 配置 max_wal_senders 变量 。 当 一 台 从 服务 器 启动 运行 或 者 一 个 
基础 备份 被 创建 时 ， 一 个 WAL 发 送 进程 将 与 客户 端 上 的 一 个 WAL 接收 进程 进行 对 话 。 
max_wal_senders 设置 允许 PostgreSQL 创建 足够 多 的 发 送 进 程 来 为 那些 客户 端 提供 服务 。 

理论 上 ， 只 有 一 个 WAL 发 送 进程 就 足够 了 。 但 那样 会 不 太 方 便 。 一 次 使 

用 --xlog-method=stream 参数 的 基础 备份 就 已 经 需要 两 个 WAL 发 送 进程 。 如 果 

全 用 户 想 要 运行 一 台 从 服务 器 并 且 同 时 执行 一 次 基础 备份 ， 就 已 经 需要 使 用 3 个 

进程 。 因 此 ， 要 确保 允许 PostgreSQL 创建 足够 多 的 进程 ， 这 样 可 以 省 下 一 些 无 

谓 的 重启 。 


然后 轮 到 hot_standby 变量 。 基 本 上 主 服务 器 会 忽略 hot_standby 变量 并 且 不 把 它 纳入 
考虑 的 范畴 ， 它 的 全 部 作用 是 让 从 服务 器 在 WAL 重 放 期 间 可 读 。 那 么 我 们 为 何 要 关心 
它 ? 记 住 这 一 点 : pg_basebackup 扩展 将 会 克隆 整个 服务 器 ， 包 括 其 配置 。 这 意味 着 如 果 
用 户 已 经 在 主 服务 器 上 设置 好 这 个 值 ， 当 数据 目录 被 克隆 时 ， 从 服务 器 将 自动 地 得 到 它 。 

在 设置 好 postgresql.conf 文件 后 ， 我 们 可 以 转向 pg_hba.conf 文件 : 通过 增加 规则 只 
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允许 从 服务 器 执行 复制 。 那 些 规则 基本 上 和 在 PITR 时 已 经 见 过 的 规则 一 样 。 

然后 像 做 PITR 时 那样 重新 启动 数据 库 服 务 器 。 

接 下 来 可 以 在 从 服务 器 上 调用 pg_basebackup 扩展 。 在 调用 前 ， 确 保 /target 目录 为 
空 。 如 果 用 户 使 用 的 是 RPM 包 ， 请 确认 已 经 关闭 可 能 运行 着 的 实例 并 且 清 空 该 目录 ( 例 
如 /varlib/pgsqldata) : 





pg_basebackup -D /target 
-h master.example.com 
--checkpoint=fast 
--xlog-method=stream -R 


只 需要 将 /target 目录 蔡 换 为 想 要 的 目标 目录 并 且 将 master.example.com 蔡 换 为 主 服务 
器 的 卫 或 者 DNS 名 称 即 可 。--checkpoint=fast 参数 将 会 触发 立刻 执行 一 个 检查 点 。 然 后 
是 --xlog-method=stream 参数 : 它 将 开启 两 个 流 。 一 个 将 复制 数据 ， 另 一 个 将 在 运行 备份 
时 被 创建 以 取得 WAL。 

最 后 是 -R 标志 : 





-R， --write-recovery-conf 
write recovery.conf after backup 


-R 标 志 实 在 是 一 种 好 特性 ， 它 让 pg_basebackup 扩展 能 自动 创建 从 服务 器 的 配置 。 它 
将 对 recovery.conf 文件 增加 一 些 项 : 


standby _ mode = on 
primary conninfo = " ... " 


第 一 个 设置 表示 PostgreSQL 应 该 一 直 重 放 WAL 一 一 如 果 所 有 的 事务 日 志 都 已 经 被 重 
放 ， 它 应 该 等 待 新 的 WAL 到 来 。 第 二 个 设置 告诉 PostgreSQL 主 服务 器 在 哪里 。 它 是 一 
个 普通 的 数据 库 连 接 。 

从 服务 器 也 能 连接 到 其 他 从 服务 器 来 流 式 接 收 事 务 日 志 。 通 过 从 一 个 从 服 
务 器 创建 基础 备份 可 以 级 联 复制 。 因 此 在 这 种 上 下 文 环境 中 ， 主 服务 器 实际 上 
意味 着 源 服务 器 。 


在 运行 了 pg_basebackup 扩展 之 后 ， 服 务 就 已 经 可 以 启动 。 第 一 件 应 该 检查 的 事情 是 
主 服务 器 上 是 否 出 现 了 WAL 发 送 进程 : 























[hselinuxpc ~]$ ps ax | grep sender 
OL ss 0:00 postgres: wal sender process 
ah ::1(57596) streaming 1F/E9000060 
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如 果 有 一 个 WAL 发 送 进程 ， 那 么 从 服务 器 也 将 运行 着 一 个 WAL 接收 进程 : 
17872 2 Ss 0:00 postgres: wal receiver process 
streaming 1F/E9000060 
如 果 那 些 进程 都 已 经 出 现 ， 就 说 明 我 们 已 经 走 上 了 正轨 并 且 复 制 已 经 按照 预期 开始 
工作 。 现 在 两 端 都 已 经 开始 进行 对 话 ，WAL 会 从 主 服 务 器 流向 从 服务 器 。 
提高 安全 性 
到 目前 为 止 ， 读 者 已 经 看 到 的 是 以 超级 用 户 流 式 传送 数据 。 但 是 ， 人 允许 来 自 远 端 的 
超级 访问 并 不 是 什么 好 主意 。 幸 运 的 是 ，PostgreSQL 允许 创建 一 个 只 被 允许 消费 事务 日 
志 流 ， 而 不 能 做 任何 其 他 事情 的 用 户 。 
创建 只 用 于 流 复制 的 用 户 很 容易 : 

test=# CREATE USER repl LOGIN REPLICATION; 

CREATE ROLE 

通过 将 replication 指派 给 该 用 户 ， 就 使 得 该 用 户 只 能 被 用 于 复制 一 一 做 任何 其 他 的 事 
情 都 会 被 禁止 。 

笔者 高 度 建议 不 要 使 用 超级 用 户 账户 设置 流 复制 ， 而 是 修改 recovery.conf 文件 使 用 
新 建 用 户 。 避 免 暴露 超级 用 户 账户 将 极 大 地 提高 安全 性 就 像 给 复制 用 户 一 个 口令 〉。 


10.3.2 ”停止 和 继续 复制 


一 旦 流 复 制 被 设置 好 ， 它 就 会 完美 无 瑕 地 工作 而 无 须 管理 员 过 多 地 介入 。 但 是 ， 在 茶 
些 情况 下 可 能 有 必要 停止 复制 并 且 在 之 后 的 某 个 时 间 继 续 它 。 为 什么 会 有 人 想 这 样 做 ? 

考虑 下 面 的 用 例 ， 用 户 负责 一 个 主 /从 设置 ， 它 运行 着 某 种 整 脚 的 CMS 或 者 某 种 靠 不 
住 的 论坛 软件 。 假 定 用 户 想 要 把 应 用 从 浆 脚 的 CMS 1.0 更 新 为 整 脚 的 CMS 2.0。 在 用 户 
的 数据 库 中 将 执行 一 些 更 改 ， 它 们 将 被 立即 复制 到 从 数据 库 中 。 如 果 更 新 处 理 做 错 了 什 
么 会 怎样 ? 由 于 有 流 复 制 ， 错 误 将 立即 被 复制 到 两 个 节点 上 。 

为 了 避免 立即 复制 ， 用 户 可 以 停止 复制 并 且 根据 需要 再 继续 。 在 CMS 更 新 例子 中 ， 
我 们 可 能 会 做 下 面 的 事情 : 

@ 停止 复制 。 

@ 在 主 服务 器 上 执行 应 用 更 新 。 

@ ”检查 应 用 是 否 仍 在 工作 。 如 果 是 ， 继 续 复制 。 否 则 故障 转移 到 复制 品 上 ， 它 仍 
有 具有 旧 数 据 。 
这 种 机 制 用 户 可 以 保护 其 数据 ， 因 为 用 户 可 以 退回 到 发 生 问 题 之 前 的 数据 。 在 


























使 





*254° 由 浅 入 深 PostereSQL 


本 章 稍 后 的 部 分 ， 读 者 将 学 到 如 何 把 一 台 从 服务 器 提升 为 新 的 主 服务 器 。 
现在 的 主要 问题 是 ， 如何 能 够 停止 复制 ?下面 是 方法 ， 在 后 备 机 上 执行 下 面 的 命令 : 
test=# SELECT pg xlog replay pause(); 

这 一 命令 将 停止 复制 。 注 意 事务 日 志 将 仍然 从 主 服务 器 流向 从 服务 器 一 一 只 有 重 放 

处 理 被 停止 。 用 户 的 数据 仍然 受到 保护 ， 因 为 它 已 经 被 持久 化 在 从 服务 器 上 。 在 服务 器 

骨 溃 的 情况 下 ， 不 会 有 数据 丢失 。 

记 住 在 从 服务 器 上 的 重 放 必 须 被 停止 ， 否 则 PostgreSQL 将 会 抛 出 一 个 错误 : 


ERROR: recovery is not in progress 





HINT: Recovery control functions can only be executed during recovery. 
一 旦 流 复制 被 继续 ， 将 需要 在 从 服务 器 上 执行 下 面 的 命令 : 
SELECT pg_xlog replay resume(); 


PostgreSQL 将 再 次 开始 重 放 xlog。 
10.3.3 ”检查 复制 以 确保 可 用 性 


每 一 位 管理 员 的 核心 任务 之 一 是 确保 复制 一 直 保持 运转 。 如 果 复 制 停摆 ， 主 服务 器 
骨 演 时 就 有 可 能 丢失 数据 。 因 此 ， 留 意 复制 是 绝对 有 必要 的 。 

幸运 的 是 ，PostgreSQL 提供 了 系统 视图 允许 用 户 深入 地 查看 系统 的 行为 。 其 中 之 一 
是 pg_stat_replication: 


test=# d pg_stat replication 
View "pg_catalog.pg stat replication" 
Column Type | Modifiers 
te EE 二 下 和 a 
pid integer 
usesysid oid 


usename name 


client addr inet 
client hostname 
client port integer 


backend start 


1 

扩 

1 

1 

1 
application name | text 

1 

1 

1 

| timestamp with time zone 

1 

1 

1 

1 


1 
1 
1 
1 
1 
text 
1 
1 
1 
1 
1 
1 


backend xmin xid 
State text 
sent location pg_lsn 


write location pg_lsn 
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flush location | pg_lsn 1 
replay location | pg lsn 1 
sync priority | integer 

sync state | text 


pg_stat_replication 视图 将 包含 发 送 者 上 的 信息 。 笔 者 这 里 不 想 使 用 主 服务 器 这 个 词 ， 
因为 从 服务 器 可 能 被 连接 在 其 他 从 服务 器 上 ， 这 样 就 有 可 能 会 构建 一 棵 服务 器 树 。 在 构 
成 服务 器 树 的 情况 下 ， 主 服务 器 将 只 有 直接 与 它 相 连 的 从 服务 器 的 信息 。 

在 这 个 视图 中 用 户 将 会 看 到 的 第 一 件 事情 是 WAL 发 送 进程 的 进程 ID。 在 有 事情 出 
错时 ， 它 可 以 帮助 用 户 识 别 进程 (通常 并 非 如 此 )〉 。 然 后 用 户 将 看 到 从 服务 器 用 来 连接 
到 其 发 送 服务 器 的 用 户 名 。client 域 将 指示 从 服务 器 在 哪里 ， 用 户 将 能 从 这 些 域 中 提取 到 
网 络 信息 。 之 后 是 backend start 域 ， 它 显示 从 服务 器 何 时 开始 从 源 服 务 器 进行 流传 送 。 

之 后 是 神奇 的 backend_ xmin 域 。 假 定 用 户 运行 一 个 主 /从 设置 ， 可 以 设置 从 服务 器 向 
主 服务 器 报告 从 服务 器 的 事务 ID 。 这 样 做 的 想法 是 延迟 主 服务 器 上 的 清理 ， 使 得 数据 不 
会 被 从 运行 在 从 服务 器 上 的 事务 中 夺 走 。 

state 域 告诉 用 户 有 关 服 务 器 的 状态 。 如 果 系 统 没 有 问题 ， 这 个 域 将 包含 streaming， 
否则 需要 更 进一步 的 观察 。 

接 下 来 的 4 个 域 很 重要 。sent_location 域 表示 有 和 多少 WAL 已 经 到 达 另 一 端 (已 被 
WAL 接收 者 接受 ) 。 用 户 可 以 使 用 它 找 出 有 多 少数 据 已 经 到 达 了 从 服务 器 。 然 后 是 write_ 
location 域 。 一 旦 WAL 已 经 被 接受 ， 它 会 被 传递 到 OS。write_location 域 将 告诉 我 们 已 经 安 
全 到 达 OS 的 WAL 位 置 。flush_ location 域 将 显示 数据 库 已 经 把 多 少 WAL 刷 到 了 磁盘 上 。 

最 后 还 有 replay_location 域 。WAL 已 经 到 达 后 备 机 的 磁盘 上 这 一 事实 并 不 表示 
PostgreSQL 已 经 重 放 了 该 WAL (对 最 终 用 户 可 见 ) 。 假 定 复制 被 暂停 ， 数 据 仍 将 流向 后 
备 机 ， 但 它 将 在 以 后 才 被 应 用 。replay_location 域 将 告诉 用 户 有 多 少数 据 已 经 可 见 。 

最 后 PostgreSQL 告诉 我 们 复制 是 同步 的 还 是 异步 的 。 

现在 问题 是 人 们 如 何 使 用 这 个 视图 得 到 关键 的 信息 ? 一 种 常见 的 用 例 是 检查 复制 延 
迟 。 下 面 是 做 法 : 


SELECT client addr, pg_current xlog location() - sent location RS diff 








FROM pg_stat replication; 


在 主 服务 器 上 运行 这 个 命令 时 ，pg_current xlog location 函数 返回 当前 的 事务 日 志 
位 置 。PostgreSQL 有 一 种 用 于 事务 日 志 位 置 的 特殊 数据 类 型 ， 叫 作 pg_lsn， 甚 至 还 有 若 
干 操作 符 可 以 用 来 从 主 服务 器 的 xlog 位 置 减 掉 从 服务 器 的 xlog 位 置 。 因 此 这 里 的 这 个 视 
图 描述 了 两 台 服 务 器 之 间 以 字 节 计 的 差 值 (复制 延迟 ) 。 

虽然 pg _stat replication 扩展 只 包含 发 送 端的 信息 ， 但 pg _stat_ wal receiver 扩展 可 以 
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提供 接收 端 上 类 似 的 信息 : 


test=# d pg stat wal _ receiveT 


View "pg catalog.pg stat wal receiver" 


Column | Type Modifiers 
EE 0 
pid integer 
status text 
receive start lsn pg_lsn 
receive start tli integer 
received lsn pg_lsn 
received tl1i integer 


last msg_ send time timestamp with time zone 


last msg receipt time | timestamp with time zone 
latest end lsn pg lsn 
latest end time timestamp with time zone 
text 


Eext 


slot name 


We ee ee ee ed i eat i he 





conninfo 


在 WAL 接收 进程 的 ID 之 后 ，PostgreSQL 将 为 用 户 提 供 进程 的 状态 。 然 后 
receive_start_lsn 域 将 告知 用 户 WAL 接收 进程 从 哪个 事务 日 志 位 置 开始 ， 而 receive_ 
start 世 域 将 告诉 我 们 WAL 接收 进程 启动 时 使 用 的 时 间 线 。 

received _lsn 域 包含 有 关 已 经 收 到 并 且 刷 入 磁盘 的 WAL 位 置 的 信息 ， 然 后 我 们 可 以 
看 到 一 些 有 关 时 间 的 信息 以 及 有 关 模 和 连接 的 信息 。 

通常 ， 很 多 人 会 觉得 阅读 pg_stat_replication 扩展 比 pg_stat_ wal receiver 扩展 更 容 
易 ， 并 且 大 部 分 工具 都 围绕 pg_stat_replication 扩展 来 构建 。 


10.3.4 执行 故障 转移 以 及 理解 时 间 线 


一 旦 创建 好 主 / 从 设置 ， 通 常 它 能 完美 无 瑕 地 工作 很 长 一 段 时 间 。 但 是 任何 事情 都 有 
可 能 失败 ， 因 此 有 必要 了 解 如 何 用 一 个 备份 系统 替换 一 个 失效 的 服务 器 。 

PostgreSQL 让 故障 转移 和 提升 变 得 很 容易 。 基 本 上 ， 用 户 需要 做 的 就 是 用 pg_ctl 参 
数 告 诉 一 个 复制 系统 提升 自己 : 

pg_ctl -D data dir promote 

该 服务 器 将 把 自己 从 主 服务 器 断 开 连接 并 且 立 即 执行 提升 。 记 住 ， 在 被 提升 时 ， 从 
服务 器 可 能 已 经 支持 着 数 千 的 只 读 连接 。PostgreSQL 一 个 很 好 的 特性 是 在 提升 期 间 所 有 
打开 的 连接 将 被 转变 成 读 写 连接 一 一 甚至 无 须 重新 连接 。 
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在 提升 一 台 服 务 器 时 ，PostgreSQL 将 增加 时 间 线 。 如 果 用 户 设置 的 是 一 台 全 新 的 服 


务 器 ， 它 会 处 于 时 间 


于 相同 的 时 间 线 。 因 
服务 器 ， 它 将 移动 到 





线 1 中 ; 如 果 从 该 服务 器 克隆 出 一 台 从 服务 器 ， 它 将 和 主 服 务 器 处 
此 ， 两 个 系统 都 是 时 间 线 1。 如 果 该 从 服务 器 被 提升 为 一 台独 立 的 主 
时 间 线 2。 








时 间 线 对 于 PITR 特别 重要 。 假 定 用 户 已 经 在 大 约 午夜 时 创建 了 一 个 基础 备份 。 在 
12.00 AM 时 ， 从 服务 器 被 提升 。 在 03.00 PM 时 某 些 东 西 崩溃 ， 并 且 用 户 想 要 恢复 到 
02.00 PA。 用 户 将 启动 以 重 放 在 基础 备份 之 后 被 创建 的 事务 日 志 ， 并 且 顺 着 用 户 想 要 的 
服务 器 的 xlog 流 继续 下 去 ， 因 为 两 个 节点 在 12.00 AM 时 发 生 了 分 叉 。 

时 间 线 改变 也 可 以 在 事务 日 志文 件 的 名 称 中 见 到 。 这 里 是 时 间 线 1 中 一 个 xlog 文件 


的 例子 : 





0000000100000000000000F5 

如 果 时 间 线 切换 到 2， 新 的 文件 名 可 能 会 是 这 样 : 
0000000200000000000000F5 

如 你 所 见 ， 来 自 不 同时 间 线 的 xlog 文件 理论 上 可 能 存在 于 同一 个 归档 目录 中 。 
10.3.5 ”管理 冲突 


现在 读者 已 经 学 了 很 多 有 关 复 制 的 内 容 。 接 下 来 ， 有 必要 看 看 复制 冲突 。 首 先 要 了 
解 的 问题 是 冲突 是 如 何 发 生 的 ? 








考虑 下 面 的 例子 : 
主 服务 器 从 服务 器 
BEGIN: 
SELECT ... FROM tab WHERE ... 
a 
DROP TABLE tab; … 冲 突 发 生 .… 

.事务 被 允许 继续 30 秒 … 
-在 超时 前 冲突 被 解决 或 者 结束 .… 

这 里 的 问题 是 ， 主 服务 器 不 知道 在 从 服务 器 上 正 运行 着 一 个 事务 。 因 此 ，DROP 





TABLE 命令 不 会 阻塞 到 读 取 事务 消失 为 止 。 如 果 那 两 个 事务 在 同一 个 节点 上 发 生 ， 阻 塞 


当然 会 发 生 。 但 是 ， 





我 们 这 里 考虑 的 是 两 台 服 务 器 。DROP TABLE 命令 将 正常 执行 ， 并 














且 一 个 从 磁盘 上 删除 那些 数据 的 请 求 也 通过 事务 日 志 到 达 从 服务 器 。 从 服务 器 就 遇 到 了 
麻烦 : 如 果 该 表 被 从 磁盘 移 除 ，SELECT 子 句 就 必须 死 掉 一 一 如 果 从 服务 器 在 应 用 那些 
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xlog 前 等 待 SELECT 子 句 完成 ， 它 又 可 能 完全 落后 于 主 服务 器 。 
理想 的 解决 方案 是 一 种 折 中 ， 它 可 以 用 一 个 配置 变量 控制 : 


max standby streaming delay = 30s 





# max delay before canceling queries 
# when reading streaming WAL; 


其 思想 是 在 通过 杀 死 从 服务 器 上 的 查询 解决 冲突 之 前 等 待 30 秒 。 根 据 用 户 的 应 用 ， 
用 户 可 能 想 要 把 这 个 变量 改 为 更 加 激进 或 者 更 加 缓和 的 设置 。 注 意 这 30 秒 是 留 给 整个 复 
制 流 而 不 是 单一 的 查询 。 可 能 会 发 生 一 个 查询 提早 很 多 被 杀 死 ， 因 为 一 些 其 他 的 查询 已 
经 等 待 了 一 段 时 间 。 

虽然 DROP TABLE 命令 是 一 种 很 明显 的 冲突 ， 但 是 还 有 一 些 不 那么 明显 的 操作 。 下 
面 是 一 个 例子 : 


BEGIN; 





DELETE FROM tab WHERE id < 10000; 
COMMIT; 


VACUUM tab; 

让 我 们 再 次 假设 在 从 服务 器 上 有 一 个 长 时 间 运 行 的 SELECT 子 句 。 

这 里 的 DELETE 子 句 显然 不 是 问题 ， 因 为 它 只 是 把 行 标记 为 删除 一 一 它 还 没有 实际 
移 除 它们 。 提 交 也 不 是 问题 ， 因 为 它 只 是 标记 事务 为 完成 。 物 理 上 ， 行 还 在 那里 。 
当 一 个 诸如 清理 的 操作 介入 时 问题 就 出 现 了 ， 它 将 毁 掉 磁盘 上 的 行 。 当 然 ， 那 些 更 
改 将 进入 xlog 并 且 最 终 达 到 从 服务 器 ， 然 后 就 又 陷入 了 麻烦 。 

要 防止 标准 OLTP 负载 导致 的 典型 问题 ，PostgreSQL 开发 组 已 经 引入 了 一 个 配置 变量 : 


hot_standby_feedback = off 
# send info from standby to prevent 





# query conflicts 


如 果 这 个 设置 为 打开 ， 从 服务 器 将 定期 发 送 最 老 的 事务 ID 给 主 服务 器 ， 然 后 清理 操 
作 将 知道 在 系统 中 某 处 运行 着 一 个 比较 老 的 事务 并 且 把 清理 延迟 到 可 以 安全 清除 那些 行 
时 再 进行 。 事 实 上 ， 当 主 服务 器 上 有 长 事务 时 ，hot_standby_feedback 参数 也 会 导致 同样 
的 效果 。 

如 你 所 见 ，hot_standby_feedback 参数 默认 为 关闭 。 为 什么 会 这 样 ? 这 样 做 有 很 好 的 
理由 ， 如 果 它 为 关闭 ， 从 服务 器 不 会 对 主 服务 器 有 实际 的 影响 。 事 务 日 志 的 流 式 传送 不 
会 消耗 很 多 CPU 能 力 ， 这 让 流 复制 廉价 且 有 效 。 不 过 ， 如 果 一 台 从 服务 器 (甚至 可 能 不 
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在 用 户 的 管控 之 下 ) 保持 事务 打开 太 久 ， 用 户 的 主 服务 器 可 能 要 忍受 延迟 清理 带 来 的 表 
膨胀 。 在 默认 设置 下 ， 相 比 减少 冲突 ， 我 们 更 不 愿意 看 到 表 膨 胀 的 情况 。 

让 hot standby _ feedback = on 通常 将 避免 99% 的 OLTP 相关 的 冲突 ， 如 果 用 户 的 事务 
比 若干 毫秒 还 要 长 ， 这 一 点 就 尤其 重要 。 


10.3.6 ”让 复制 更 可 靠 


在 本 章 中 ， 读 者 已 经 看 到 设置 复制 很 简单 ， 不 需要 花费 多 大 功夫 。 但 是 ， 总 是 会 有 
一 些 能 够 带 来 挑战 的 极限 情况 。 其 中 之 一 就 是 事务 日 志保 留 。 

考虑 下 面 的 情景 : 

@ 取得 一 个 基础 备份 。 

@ 在 备份 后 一 个 小 时 内 没有 事情 发 生 。 

@ ”从 服务 器 启动 。 

记 住 主 服 务 器 并 不 太 在 乎 从 服务 器 的 存在 性 。 因 此 ， 从 服务 器 启动 所 需要 的 事务 日 
志 可 能 已 经 不 再 存在 于 主 服务 器 之 上 ， 因 为 它们 可 能 已 经 被 检查 点 所 移 除 。 问 题 是 ， 要 
启动 从 服务 器 ， 就 需要 一 次 重新 同步 。 在 数 TB 数据 库 的 情况 下 ， 这 显然 是 个 问题 。 

这 个 问题 的 一 种 可 能 的 解决 方案 是 使 用 wal_keep_segments 设置 : 


wal_ keep segments = 0 # in logfile segments，16MB each; 0 disables 


默认 情况 下 ，PostgreSQL 会 保留 足够 多 的 事务 日 志 以 应 付 意外 崩溃 ， 但 保留 的 不 是 
太 多 。 通 过 wal keep_segments 设置 ， 用 户 可 以 告诉 服务 器 保留 更 多 数据 ， 这 样 即使 一 台 
从 服务 器 落后 了 ， 它 也 能 追赶 上 来 。 

有 必要 记 住 服 务 器 不 仅 会 因为 本 身 过 慢 或 者 过 忙 而 落后 一 很 多 情况 下 延迟 的 发 生 
是 由 于 网 络 太 慢 。 假 设 用 户 正在 一 个 1TB 的 表 上 创建 索引 ，PostgreSQL 排序 数据 ， 并 且 
在 实际 构建 索引 时 把 它 也 发 送 到 事务 日 志 。 想 象 一 下 要 在 一 条 可 能 只 能 处 理 1G 比特 的 线 
路 上 发 送 数 百 兆 字 节 的 xlog 意味 着 什么 ， 数 秒 之 内 还 会 有 很 多 数 GB 的 数据 可 能 随后 到 
来 。 因 此 ， 调 整 wal keep_segments 设置 不 应 局 限于 典型 的 延迟 而 是 管理 员 可 容忍 的 最 高 
延迟 〈 可 能 是 某 种 安全 范围 ) 。 

为 wal keep_segments 研究 一 种 较 高 且 合理 的 设置 很 有 意义 ， 笔 者 推荐 确保 总 是 有 足 
够 的 数据 。 
事务 日 志 耗 尽 问题 的 另 一 种 解决 方案 是 复制 槽 ， 将 在 本 章 后 面 的 部 分 介绍 。 


10.4 升级 到 同步 复制 


到 目前 为 止 ， 我 们 已 经 比较 详细 地 介绍 了 异步 复制 。 不 过 ， 异 步 复 制 意味 着 允许 从 
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服务 器 上 的 提交 在 主 服 务 器 上 的 提交 之 后 发 生 。 如 果 主 服务 器 崩 演 ， 即 便 使 用 复制 ， 还 
没有 到 达 从 服务 器 的 数据 仍 有 可 能 丢失 。 
同步 复制 可 以 解决 这 个 问题 ， 如 果 PostgreSQL 同步 进行 复制 ， 一 次 提交 只 有 被 至 少 
一 个 复制 系统 刷 入 磁盘 后 才能 在 主 服务 器 上 完成 。 因 此 ， 同 步 复 制 本 质 上 能 大 幅度 降低 
数据 丢失 的 几率 。 
在 PostgreSQL 中 ， 配 置 同步 复制 也 很 容易 。 基 本 上 ， 只 需要 做 两 件 事情 : 
@ 调整 主 服 务 器 上 postgresql.conf 文件 中 的 synchronous_standby_names 设置 。 
@ 为 复制 系统 的 recovery.conf 文件 中 的 primary_conninfo 参数 增加 一 个 
application name 设置 。 
让 我 们 从 主 服 务 器 上 的 postgresql.conf 文件 开始 : 
synchronous_standby names = "" 
# standby servers that provide sync rep 
# number of sync standbys and comma-separated 
# list of application name 
# from standby(s); '*' = all 
如 果 放 入 的 是 “*”， 所 有 节点 都 将 被 作为 同步 候选 。 不 过 ， 在 实际 生活 场景 中 很 可 
能 只 有 若干 个 节点 将 被 列 出 。 例 如 : 


synchronous_standby names = 'slavel, slave2, slave3' 


现在 我 们 必须 更 改 recovery.conf 文 件 并 且 增 加 application_name: 


primary_conninfo = '... application name=slave2" 


这 个 复制 系统 将 作为 slave2 连接 到 主 服务 器 。 主 服务 器 将 检查 其 配置 并 且 发 现 slave2 
是 列表 中 列 出 的 可 行 从 服务 器 之 一 。 因 此 ，PostgreSQL 就 能 保证 只 有 在 从 服务 器 确认 拿 
到 一 个 事务 后 该 事务 才能 在 主 服务 器 上 成 功 提交 。 

现在 假设 slave2 由 于 某 种 原因 宕 机 ，PostgreSQL 将 尝试 把 其 他 两 个 节点 之 一 转变 成 
一 个 同步 后 备 机 。 现 在 的 问题 是 ， 如 果 没有 其 他 的 服务 器 会 怎样 ? 在 这 种 情况 下 ， 如 果 
有 务 被 认为 是 同步 的 ，PostgreSQL 将 一 直 等 待 提交 。 是 的 ， 就 是 这 样 ，PostgreSQL 将 不 
会 继续 提交 ， 除 非 有 至 少 两 个 可 行 节点 可 用 。 记 住 ， 用 户 已 经 要 求 PostgreSQL 在 至 少 两 
个 节点 上 存储 数据 一 一 如 果 在 任意 给 定时 间 点 用 户 无 法 提供 足够 多 的 主机 ， 那 是 用 户 的 
普 。 实 际 上 ， 这 意味 着 同步 复制 的 最 佳 实现 是 至 少 3 个 节点 ， 因 为 这 样 总 是 可 以 有 损失 
一 台 主 机 的 机 会 。 

谈 到 主机 失效 ， 有 必要 提 到 一 点 ， 如 果 一 个 同步 伙伴 在 提交 进行 时 死 掉 ，PostgreSQL 
将 等 待 它 回来 。 此 外 ， 同 步 提 交 可 能 会 发 生 在 某 个 其 他 潜在 的 同步 伙伴 上 。 最 终 用 户 其 
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至 可 能 不 会 意识 到 同步 伙伴 发 生 了 变化 。 

在 一 些 情 况 下 ， 仅 在 两 个 结 点 上 保存 数据 可 能 不 够 ， 也 许 用 户 想 要 更 多 地 提高 安全 
性 并 且 在 更 多 节点 上 存储 数据 。 为 了 实现 这 一 点 ， 用 户 可 以 使 用 下 面 的 语法 〈 在 
PostgreSQL 9.6 或 更 高 版 本 中 ) : 


synchronous standby names = 
"4(slavel, slave2, slave3, slave4, slave5, slave6)"' 


在 这 种 情况 下 ， 在 主 服务 器 确认 提交 之 前 ， 数 据 被 认为 会 落 在 6 个 节点 中 的 4 个 之 上 。 
然 ， 这 样 做 是 有 代价 的 一 一 记 住 如 果 用 户 增加 越 来 越 多 的 同步 复制 系统 ， 速 度 将 
会 下 降 ， 天 下 没有 免费 的 午餐 。 为 了 保持 性 能 开销 可 控 ，PostgreSQL 提供 了 若干 方法 ， 
在 接 下 来 的 小 节 中 将 会 讨论 它们 。 

@ 调整 持久 性 

在 本 章 中 ， 读 者 已 经 看 到 数据 可 以 被 同步 地 或 者 异步 地 复制 。 不 过 ， 这 并 非 流 复制 

的 全 部 。 为 了 确保 好 的 性 能 ，PostgreSQL 允许 用 户 以 非常 灵活 的 方式 配置 复制 中 涉及 的 
各 类 事情 。 可 以 同步 或 者 异步 复制 所 有 东西 ， 但 是 在 很 多 情况 下 用 户 可 能 想 要 以 更 细 粒 
度 的 方式 来 运行 ， 这 时 就 需要 synchronous_commit 设置 。 

假定 已 经 配置 了 同步 复制 〈 recovery.conf 文件 中 的 application name 设置 以 及 

postgresql.conf 文件 中 的 synchronous_standby_names 设置 ) ，synchronous_commit 设置 将 
提供 下 列 选项 。 

@ off: 这 本 质 上 就 是 异步 复制 。 在 主 服务 器 上 WAL 不 会 被 立即 刷 到 磁盘 ， 并 且 
主 服务 器 不 会 等 待 从 服务 器 把 所 有 东西 都 写 到 磁盘 。 如 果 主 服务 器 失效 ， 一 些 
数据 可 能 会 丢失 (最 多 是 wal_writer delay 的 3 倍 ) 。 

@ ”local: 主 服务 器 上 提交 时 事务 日 志 被 刷 到 磁盘 。 但 是 ， 主 服务 器 不 等 待 从 服务 
器 (异步 复制 )。 

@ remote write: remote_write 设置 就 已 经 能 让 PostgreSQL 进行 同步 复制 。 不 过 ， 
只 有 主 服务 器 会 把 数据 保存 到 磁盘 。 对 于 从 服务 器 ， 把 数据 发 送 到 操作 系统 就 
够 了 。 其 思想 是 不 要 等 待 第 二 次 盘 刷 写 以 提高 速度 。 两 种 存储 系统 正好 在 同一 
时 间 裔 溃 的 可 能 性 非常 低 。 因 此 ， 数 据 损 失 的 风险 近乎 于 零 。 

@ on: 在 这 种 情况 下 ， 如 果 主 服务 器 和 从 服务 器 都 已 经 成 功 地 把 一 个 事务 刷 到 了 
磁盘 ， 那 么 这 个 事务 就 没有 问题 了 。 只 有 数据 被 安全 地 保存 在 两 台 服 务 器 上 
(或 者 更 多 服务 器 ， 取 决 于 配置 ) 后 ， 应 用 才 会 收 到 提交 成 功 的 通知 。 

@ remote apply: 虽然 on 能 确保 数据 被 安全 地 存储 在 两 个 节点 上 ， 但 它 不 保证 能 
够 马上 做 到 负载 均衡 。 数 据 被 刷 到 磁盘 上 并 不 能 确保 用 户 已 经 可 以 看 到 该 数 
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据 。 例 如 ， 如 果 存 在 冲突 ， 从 服务 器 将 停止 事务 重 放 一 一 然后 ， 冲 突 期 间 事务 
日 志 仍 将 被 发 送 给 从 服务 器 并 且 被 刷 到 磁盘 上 。 简 而 言 之 ， 可 能 会 发 生 数据 被 
刷 到 从 服务 器 上 但 对 最 终 用 户 还 不 可 见 的 情况 。remote_apply 能 解决 这 一 问题 。 
它 确 保 数据 必须 在 复制 系统 上 可 见 ， 这 样 接 下 来 的 读 请 求 可 以 被 安全 地 在 从 服 
务 器 上 执行 ， 这 些 请 求 已 经 能 够 看 到 对 主 服务 器 所 作 的 更 改 并 且 把 更 改 显示 给 
最 终 用 户 。 
当然 ，remote_apply 是 一 种 最 慢 的 复制 数据 的 方法 ， 因 为 它 要 求 等 待 从 服务 器 把 数据 
披露 给 最 终 用 户 。 
在 PostgreSQL 中 ，synchronous_commit 参数 不 是 一 个 全 局 值 。 就 像 很 多 其 他 设置 一 
样 ， 可 以 在 多 个 级 别 上 调整 这 个 参数 。 用 户 可 能 会 这 样 做 : 
test=# ALTER DATABASE test SET synchronous commit TO off; 
ALTER DATABASE 


有 时 候 ， 只 有 单个 数据 库 应 该 以 特定 的 方式 进行 复制 。 还 可 以 在 作为 特定 用 户 连接 
时 只 做 同步 复制 。 最 后 但 并 非 最 不 重要 的 ， 还 可 以 告诉 单个 事务 如 何 提交 。 通 过 即时 调 
整 synchronous_commit 参数 ， 甚 至 可 以 以 每 个 事务 的 级 别 进行 控制 。 

例如 ， 考 虑 下 面 的 两 种 场景 : 

@ 写 入 一 个 日 志 表 ， 在 其 中 用 户 可 能 想 要 使 用 异步 提交 ， 因 为 希望 更 快 。 

@ 存储 一 次 信用 卡 付款 ， 在 其 中 可 能 希望 更 安全 ， 因 此 用 户 可 能 想 要 使 用 同步 事务 。 

如 你 所 见 ， 根 据 什 么 数据 被 修改 ， 同 一 个 数据 库 可 能 有 不 同 的 需求 。 因 此 ， 在 事务 
级 别 更 改 数据 非常 有 用 并 且 有 助 于 提高 速度 。 


10.5 利用 复制 档 























在 介绍 了 同步 复制 和 动态 可 调整 的 持久 性 之 后 ， 笔 者 想 要 把 读者 的 注意 力 转 到 一 种 
被 称 为 复制 槽 的 特性 上 。 

复制 槽 的 目的 是 什么 ? 让 我 们 考虑 下 面 的 例子 : 有 一 台 主 服务 器 和 一 台 从 服务 器 。 
在 主 服 务 器 上 ， 执 行 一 个 大 型 的 事务 并 且 网 络 连接 不 足以 及 时 传送 所 有 的 数据 。 在 某 时 
刻 ， 主 服务 器 移 除 了 它 的 事务 日 志 〈 检 查 点 ) 。 如 果 从 服务 器 落后 太 多 ， 就 需要 一 次 重新 
同步 。 正 如 在 前 文 已 经 见 到 的 ，wal keep_segments 设置 可 以 被 用 来 降低 复制 失败 的 风险 。 
但 问题 是 ，wal keep_segments 设置 的 最 佳 值 是 多 少 ? 当然 ， 越 多 越 好 ， 但 多 少 是 最 好 ? 

复制 槽 将 为 用 户 解决 这 一 问题 : 如 果 用 户 使 用 复制 槽 ， 主 服务 器 只 能 在 事务 日 志 被 
所 有 复制 系统 消费 过 后 重用 它 。 其 优点 是 从 服务 器 绝 不 会 落后 太 多 以 至 于 需要 重新 同 
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步 。 但 问题 是 ， 假 定 用 户 在 没有 告知 主 服务 器 的 情况 下 关闭 了 一 个 复制 系统 。 主 服务 器 
将 永远 保持 事务 日 志 并 且 主 服务 器 上 的 磁盘 将 最 终 填 满 导致 不 必要 的 停机 。 

为 了 降低 主 服 务 器 的 风险 ， 复 制 槽 应 该 只 和 适当 的 监控 以 及 告警 措施 一 起 使 用 。 有 
必要 关注 打开 的 复制 槽 ， 它 们 可 能 会 导致 问题 或 者 可 能 没有 继续 被 使 用 。 

在 PostgreSQL 中 有 两 种 类 型 的 复制 槽 : 

@ 物理 复制 槽 。 

@ ”逻辑 复制 权 。 

物理 复制 横 可 以 被 用 于 标准 的 流 复制 。 它 们 将 确保 数据 不 会 被 过 早 重用 。 逻 辑 复制 
槽 做 的 是 相同 的 事情 ， 但 它们 被 用 于 逻辑 解码 。 逻 辑 解 码 的 思想 是 让 用 户 有 机 会 挂 接 到 
事务 日 志 并 且 用 一 个 插件 对 它 解码 。 因 此 逻辑 事务 槽 可 以 看 作 是 对 数据 库 实 例 做 了 某 种 
tail -f。 它 允许 提取 对 数据 库 做 的 更 改 ， 并 且 可 以 输出 成 任意 格式 的 事务 日 志 并 且 可 用 于 
任何 目的 。 在 很 多 情况 下 逻辑 复制 槽 被 用 于 逻辑 复制 。 


10.5.1 处理 物理 复制 模 
要 使 用 复制 槽 ， 必 须 对 postgresql.conf 文件 做 出 更 改 : 


wal_level = logical 

max replication slots = 5 # or whatever number is needed 

有 了 物理 模 ， 逻 辑 就 不 是 必需 的 了 一 一 replica 就 足够 了 。 不 过 ， 对 于 逻辑 模 ， 我 们 
需要 更 高 的 wal_level 设置 ， 然 后 必须 更 改 max_replication slots 设置 。 说 白 了 ， 只 需要 放 
入 一 个 服务 用 户 目的 所 需 的 数字 就 好 。 笔 者 的 推荐 是 加 上 一 些 空闲 的 槽 ， 这 样 可 以 轻易 
地 接 入 更 多 消费 者 而 无 须 重 启 服务 器 。 

在 重启 后 ， 模 就 已 经 可 以 被 创建 了 : 

test=# x 

Expanded display is on. 














test=# df *create*physical*slot* 
List of functions 


SRECORDl EE 
Schema pg_catalog 
Name pg_create physical replication slot 


Result data type record 


1 
1 
1 
Argument data types | slot name name, 
immediately reserve boolean DEFAULT false, 


OUT slot name name, 
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OUT xlog position pg lsn 


Type | normal 

这 里 的 pg_create_physical replication_ slot 函数 帮助 用 户 创建 槽 。 它 可 以 用 一 个 或 者 
两 个 参数 调用 : 在 只 传 入 一 个 槽 名 称 的 情况 下 ， 模 将 在 第 一 次 被 使 用 时 激活 。 如 果 true 
被 作为 第 二 个 参数 传 入 ， 模 将 立即 开始 保留 事务 日 志 : 


test=# SELECT * 
FROM pg create physical replication slot('some slot name', true); 





slot name | xlog position 
ES 4 
some slot name | 0/EF8AD1D8 
(1 row) 


要 查看 主 服务 器 上 有 多 少 个 活动 的 槽 ， 考 虑 运行 下 面 的 SQL 语句 : 


test=# x 
Expanded display is on. 

test=# SELECT * FROM pg replication slots; 
= RECORD 1 -===== 于 一 二 二 二 一 一 一 二 = 一 
Slot_name some_slot name 
plugin 
slot type physical 
datoid 
database 
active 下 
active pid 
xmin l 
catalog xmin 
restart lsn 0/EF8AD1D8 
confirmed flush lsn 


该 视图 将 告诉 我 们 很 多 有 关 槽 的 信息 。 它 包含 有 关 使 用 中 的 槽 的 类 型 、 事 务 日 志 位 
置 等 的 信息 。 

要 使 用 槽 ， 所 需要 做 的 就 是 把 它 加 入 recovery.conf 文 件 中 : 

primary_ slot name = 'some slot name" 

一 旦 流 被 重启 ， 权 将 被 直接 使 用 并 且 保 护 复制 。 

如 果 用 户 不 再 需要 槽 ， 可 以 很 容易 地 删 掉 它 : 


test=# df *drop*slot* 


List of functions 





Wh 
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三 EBD) 本 一 和 一 一 一 一 一 一 一 一 一 
Schema | pg_catalog 

Name | pg_drop replication slot 
Result data type | void 

Argument data types | name 

Type | normal 


在 模 被 删除 时 ， 就 不 再 有 届 辑 槽 和 物理 槽 的 区 分 。 只 需 向 该 函数 传递 槽 的 名 称 并 且 
执行 它 即 可 。 
C9 注意 当 楼 被 删除 时 ， 不 允许 任何 人 使 用 它 。 否 则 ，PostgreSQL 将 会 报错 
( 有 充分 的 理由 )。 





10.5.2 ”处 理 逻 辑 复制 模 


逻辑 复制 柳 对 于 逻辑 复制 来 说 极其 重要 。 不 幸 的 是 ， 由 于 篇 幅 限制 ， 本 章 无 法 覆盖 
到 逻辑 复制 的 所 有 方面 。 不 过 ， 笔 者 想 要 勾勒 出 一 些 基 本 概念 ， 它 们 对 于 风 辑 解码 和 由 
辑 复制 都 非常 重要 。 

如 果 用 户 想 要 创建 一 个 复制 槽 ， 其 做 法 如 下 面 的 示例 。 这 里 需要 的 函数 需要 两 个 参 
数 ， 第 一 个 参数 定义 复制 槽 的 名 称 ， 而 第 二 个 参数 指定 用 于 解码 事务 日 志 的 插件 。 它 决 
定 PostgreSQL 用 来 返回 数据 的 格式 : 

test=# SELECT * 

FROM pg_create logical replication slot('logical slot', 
'test _ decoding'); 


slot_ name | xl0og position 
ME pe 
logical slot | 0/EF8AD4BO 
(1 row) 


用 户 可 以 使 用 与 前 文 相同 的 命令 检查 现 有 的 槽 。 
为 了 向 读者 展示 覃 实际 能 做 什么 ， 我 们 先 创建 一 个 小 的 测试 : 


test=# CREATE TABLE t demo (id int, name text, payload text); 
CREATE TABLE 

test=# BEGIN; 

BEGIN 

test=# INSERT INTO t demo VALUES (1, ‘hans', "Some data'); 
INSERT 0 1 

test=# INSERT INTO t demo VALUES (2, "paul'， "Some more data'); 
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INSERT 0 1 

test=# COMMIT; 

COMMIT 

test=# INSERT INTO t demo VALUES (3, 'joe', 'less data'); 
INSERT 0 1 


注意 有 两 个 事务 会 被 执行 。 这 些 事务 所 作 的 更 改 现在 可 以 从 槽 中 提取 出 来 : 


test=# SELECT pg logical slot get changes('logical slot', NULL, NULL); 
pg_logical slot get changes 





(0/EF8AFS5BO, 606546, "BEGIN 606546") 

(0/EF8CCCAO, 606546, "COMMIT 606546") 

(0/EF8CCCD8, 606547, "BEGIN 606547") 

(0/EF8CCCD8, 606547, "table public.t demo: INSERT: id[integer]:1 
name[text]:'hans' payload[text]:'some data'") 

(0/EF8CCD60, 606547, "table public.t demo: INSERT: id[integer]:2 
name [text] : "paul' payload[text]:"'some more data'™") 

(0/EF8CCDE0,606547, "COMMIT 606547") 

(0/EF8CCE18, 606548, "BEGIN 606548") 

(0/EF8CCE18, 606548, "table public.t demo: INSERT: id[integer]:3 
name [text]:'joe' payload[text]:'less data'") 

(0/EF8CCE98, 606548, "COMMIT 606548") 





(9 rows) 

这 里 使 用 的 格式 取决 于 之 前 我 们 选择 的 输出 插件 。PostgreSQL 有 多 种 输出 插件 ， 例 
如 wal2json 之 类 。 

注意 在 使 用 默认 值 的 情况 下 ， 逻 辑 流 将 包含 真实 值 而 不 只 是 函数 。 逻 辑 流 中 有 最 终 
出 现在 底层 表 中 的 数据 。 





还 要 记 住 槽 中 的 数据 一 旦 被 消费 掉 就 再 也 不 会 被 返回 : 
test=# SELECT pg_ logical slot get changes('logical slot', NULL, NULL); 
pg logical slot get changes 








因此 ， 第 二 次 调用 的 结果 集 为 空 。 如 果 用 户 想 重复 取得 数据 ，PostgreSQL 提供 了 
pg_logical_ slot_peek_changes 函数 。 其 作用 类 似 于 pg_logical_slot_get_changes 函数 ， 但 它 
能 保证 数据 在 槽 中 仍然 可 用 。 

当然 ， 使 用 纯 SQL 并 非 消费 事务 日 志 的 唯一 方式 。 还 有 一 个 名 为 pg_recvlogical 扩展 
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的 工具 。 它 的 功能 可 以 类 比 为 在 一 整个 数据 库 实例 上 做 tail -f 并 且 实 时 接收 数据 流 。 
让 我 们 启动 pg_recvlogical 扩展 : 


[hs@zenbook ~]$ pg recvlogical -S logical slot -P test decoding 





dtest Upostgresi Start £0 


在 这 种 情况 下 ， 该 工具 连接 到 测试 数据 库 并 且 消 费 来 自 于 logical_slot 的 数据 。-f - 意 
味 着 流 将 被 发 送 到 stdout。 

让 我 们 删 掉 一 些 数据 : 

test=# DELETE FROM t demo WHERE id < random()*10; 

DELETE 3 


这 些 更 改 将 会 进入 事务 日 志 。 但 是 ， 数 据 库 默认 只 关心 删除 后 表 会 是 什么 样 。 它 知 
道 必 须 触 碰 哪 些 块 等 一 一 它 不 知道 以 前 是 什么 : 


BEGIN 606549 
table public.t demo: DELETE: (no-tuple-data) 
table public.t demo: DELETE: (no-tuple-data) 
table public.t demo: DELETE: (no-tuple-data) 
COMMIT 606549 


因此 ， 这 种 数据 几乎 没有 意义 。 为 了 弥补 这 一 点 ， 可 以 使 用 下 面 的 命令 : 


test=# ALTER TABLE t demo REPLICA IDENTITY FULL; 
ALTER TABLE 


如 果 该 表 被 重新 填 入 数据 并 且 被 再 次 删除 ， 事 务 日 志 流 会 像 这 样 : 

BEGIN 606558 

table public.t demo: DELETE: id[integer]:1 name[text]:'hans' 
payload[text]:'some data'" 

table public.t demo: DELETE: id[integer]:2 name[text]:'paul' 
payload[text]:'some more data' 

table public.t demo: DELETE: id[integer]:3 name [text]:'joe' 


payload[text]:'less data'" 
COMMIT 606558 


现在 可 以 看 到 所 有 的 更 改 。 

@ 远 辑 槽 用 例 

有 多 种 复制 槽 的 用 例 。 最 简单 的 用 例如 下 ， 数 据 可 以 被 从 服务 器 以 想 要 的 格式 得 到 
并 且 被 用 于 审计 、 调 试 或 者 监控 数据 库 实 例 。 
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下 一 个 逻辑 步骤 当然 是 取得 更 改 流 并 且 把 它 用 于 复制 。BDR 之 类 的 解决 方案 完全 依 
赖 于 逻辑 解码 ， 因 为 二 进 制 级 别 的 更 改 在 多 主 服务 器 复制 的 情况 下 无 法 工作 。 

最 后 ， 有 时 会 需要 在 不 停机 的 情况 下 进行 升级 。 记 住 ， 二 进 制 事务 日 志 流 不 能 被 用 
来 在 不 同 版 本 的 PostgreSQL 之 间 进 行 复制 。 因 此 ， 未 来 版 本 的 PostgreSQL 将 支持 一 种 名 
为 pglogical 的 工具 ， 它 可 以 帮助 进行 不 停机 升级 。 




















10.6 总 结 


在 本 章 中 ， 读 者 已 经 学 到 了 PostgreSQL 复制 的 大 部 分 重要 特性 ， 例 如 流 复制 和 复制 
冲突 。 读 者 已 经 学 到 了 PITR 和 复制 槽 。 注 意 除非 一 本 关于 复制 的 书 超过 400 页 ， 否 则 它 
绝 不 算 完整 。 但 是 读者 已 经 学 到 了 每 一 个 管理 员 应 该 知道 的 最 重要 的 事情 。 

第 11 章 将 介绍 对 PostgreSQL 有 用 的 扩展 。 读 者 将 学 到 已 经 被 工业 界 广泛 采用 的 扩 
展 ， 以 及 提供 更 多 功能 的 扩展 。 
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在 本 书 的 第 10 章 中 ， 我 们 关注 了 复制 、 事 务 日 志 传 输 以 及 逻辑 解码 。 这 些 内 容 大 多 
与 管理 相关 ， 现 在 我 们 的 目标 是 介绍 更 加 广泛 的 主题 。 在 PostgreSQL 世界 中 ， 很 多 事情 
都 通过 扩展 完成 。 扩 展 的 优点 是 可 以 在 不 膨胀 PostgreSQL 核心 的 前 提 下 为 核心 增加 功 
能 。 人 们 可 以 从 功能 相似 的 扩展 中 进行 选择 并 且 找到 最 适合 自己 的 那 一 个 。 

本 章 将 讨论 一 些 PostgreSQL 最 广泛 使 用 的 扩展 。 不 过 ， 在 深入 这 些 内 容 前 笔者 做 一 
点 声明 : 本 章 只 是 介绍 了 笔者 个 人 觉得 有 用 的 扩展 ， 现 在 还 有 很 多 模块 ， 本 书 不 可 能 以 
一 种 合适 的 方式 将 它们 全 部 覆盖 。 每 天 都 有 东西 被 发 布 出 来 ， 有 时 甚至 连 专业 人 员 都 很 
难 注意 到 全 部 的 扩展 。 

本 章 将 覆盖 下 列 主题 

@ 扩展 如 何 工作 。 

@ 一 批 contrib 模块 。 

@ GIS 相关 模块 速 览 。 

@ 其 他 有 用 的 扩展 。 

注意 本 章 只 会 覆盖 最 重要 的 扩展 。 


11.1 理解 扩展 如 何 工作 














在 深入 可 用 的 扩展 之 前 ， 有 必要 首先 看 看 扩展 如 何 工作 ， 理 解 扩 展 机 制 的 内 部 工作 
方式 是 非常 有 益处 的 。 
首先 看 看 语法 : 
test=# \h CREATE EXTENSION 
Command: CREATE EXTENSION 
Description: install an extension 
Syntax: 
CREATE EXTENSION [ IF NOT EXISTS ] extension name 
[ WITH ] [ SCHEMA schema name ] 
[ VERSION version ] 
[ FROM old version ] 
[ CASCADE ] 
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当 用 户 想 要 部 署 一 个 扩展 时 ， 只 要 简单 地 调用 CREATE EXTENSION 子 句 。 它 将 检 
查 该 扩展 并 且 把 扩展 载 入 用 户 的 数据 库 中 。 注 意 ， 扩 展 将 被 载 入 一 个 数据 库 而 不 是 整个 
数据 库 实例 。 
如 果 用 户 装 载 一 个 扩展 ， 用 户 可 以 决定 要 使 用 哪 一 个 方案 。 很 多 扩展 都 能 被 重 定 
位 ， 因 此 用 户 可 以 选择 使 用 的 方案 。 然 后 可 以 选 定 扩展 的 一 个 特定 版 本 ， 常 常会 有 用 户 
不 想 部 署 最 新 版 本 扩展 的 情况 ， 因 为 其 客户 端 还 运行 着 过 时 的 软件 。 在 这 种 情况 下 ， 在 
系统 上 部 署 任 意 可 用 版 本 的 能 力 可 能 会 带 来 便利 。 

FROM old_version 子 句 需要 多 加 注意 。 在 旧时 代 ，PostgreSQL 并 不 支持 扩展 ， 因 此 
仍 有 很 多 未 打包 的 代码 存在 。 这 个 选项 让 CREATE EXTENSION 子 句 能 够 运行 一 个 安装 
脚本 来 把 现 有 的 对 象 吸收 到 扩展 中 ， 而 不 是 创建 新 的 对 象 。 注 意 ，SCHEMA 子 句 指定 包 
含 这 些 预先 存在 对 象 的 方案 ， 只 有 在 拥有 旧 模 块 时 才 需 要 使 用 它 。 

最 后 还 有 CASCADE 子 句 。 一 些 扩展 依赖 于 其 他 扩展 ，CASCADE 选项 也 会 自动 地 
部 署 那些 软件 包 。 例 如 : 

test=# CREATE EXTENSION earthdistance; 


ERROR: required extension "cube" is not installed 
HINT: Use CREATE EXTENSION ... CASCADE to install required extensions too. 


earthdistance 是 一 个 实现 了 大 圆 距离 计算 的 模块 。 读 者 可 能 知道 ， 地 面 上 两 点 间 的 最 
短 距 离 并 非 直线 。 恰 恰 相 反 ， 飞 行 员 必须 不 断 地 调整 其 航向 以 寻找 从 一 点 飞 往 另 一 点 的 最 
快 路 径 。 问 题 是 : earthdistance 扩展 依赖 于 cube 扩 展 ， 后 者 允许 用 户 在 球体 上 执行 操作 。 

为 了 自动 部 署 这 种 依赖 ， 如 前 所 述 ， 可 以 使 用 CASCADE 子 句 : 

test=# CREATE EXTENSION earthdistance CASCADE; 


NOTICE: installing required extension "cube" 
CREATE EXTENSION 


在 这 种 情况 下 ， 两 个 扩展 都 将 被 部 署 。 
@ ”检查 可 用 的 扩展 
PostgreSQL 提供 了 多 个 视图 来 确定 系统 中 有 哪些 扩展 以 及 哪些 实际 被 部 署 。 其 中 之 


一 是 pg available_extensions: 























test=# \d pg available extensions 
View "pg_catalog.pg available extensions" 


Column | Type | Modifiers 
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default version I text | 
installed version | text | 


comment | text | 


它 包含 了 所 有 可 用 扩展 的 列表 ， 包 括 它 们 的 名 称 、 默 认 版 本 以 及 当前 安装 的 版 本 。 
为 了 让 最 终 用 户 更 容易 使 用 它 ， 其 中 还 有 一 段 描述 告诉 我 们 更 多 有 关 该 扩展 的 信息 。 
下 面 的 列表 包含 两 个 从 pg_available_extensions 中 取出 的 行 : 


下 ES 三 亲 N 玉 
Expanded display is on. 
test=# SELECT * FROM pg available extensions LIMIT 2; 


Con 和 
name earthdistance 
default version se 


installed version 6 


comment calculate great-circle distances on the surface of 
the Earth 

-[ RECORD 2 ]----- 十 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 

name plpgsql 

default version 1=0 


installed version | 1.0 





comment PL/pgSQL procedural language 


如 你 所 见 ， 在 笔者 的 数据 库 中 earthdistance 和 plpgsql 扩展 都 被 启用 。plpgsql 扩展 默 
认 就 在 那里 而 earthdistance 则 是 刚刚 和 cube 一 起 被 加 入 的 。 这 个 视图 的 一 个 好 处 是 用 户 
可 以 很 快 地 得 到 安装 了 什么 以 及 可 以 安装 什么 的 总 览 。 

但 是 在 一 些 情况 下 ， 扩 展 的 可 用 版 本 不 止 一 个 。 为 了 找 出 更 多 有 关 版 本 的 信息 ， 可 
以 考虑 检查 下 面 的 视图 : 


test=# \d pg available extension versions 





View "pg_catalog.pg available extension versions" 


Column | Type | Modifiers 
Re 和 
name | name 1 
Version | text 
installed | boolean | 
superuser | boolean | 
1 1 


relocatable boolean 
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Schema | name 
requires | name[] 
comment | text 


如 下 一 个 列表 所 示 ， 其 中 还 有 更 多 详细 的 信息 可 用 : 


test=# SELECT * FROM pg available extension versions LIMIT 1; 





= RBCORD 区 > 1] = == > > 
name earthdistance 

version 了 二 

installed 生 

superuser 让 

relocatable 在 

Schema 

requires {cube} 

comment calculate great-circle distances on the surface of the 


Earth 


PostgreSQL 还 告诉 用 户 扩展 是 否 可 以 被 重 定位 ， 它 被 部 署 在 哪个 方案 中 以 及 需要 其 
他 哪些 扩展 。 然 后 有 描述 该 扩展 的 注释 ， 这 个 之 前 已 经 展示 过 。 

现在 的 主要 问题 是 ，PostgreSQL 从 哪里 找到 有 关系 统 上 扩展 的 所 有 信息 ? 假定 用 户 
已经 从 官方 的 PostgreSQL RPM 仓库 部 署 了 PostgreSQL 9.6，/usrpgsql-9.6/share/extension 
目录 将 包含 若干 文件 : 


-bash=4239 Ls =] citoxts 
root root 1028 Oct 26 13:28 citext--1.0--1.1.sql 
root root 2748 Oct 26 13:28 citext--1.1--1.2.sql 


1 
1 
=TW=E==T==, 1 Eo0Ot root 307 Oct 26 13:28 citext--1.2--1.3.sql 
和 
1 
1 


eh 
人 二 一 root root 12991 Oct 26 13:28 citext--1.3.sql 
root root 158 Oct 26 13:28 citext.control 
root root 9781 Oct 26 13:28 citext-unpackaged--1.0.sql 


ER 


= 人 EW 二 = 


citext( 大 小 写 不 敏感 文本 ) 扩展 的 默认 版 本 为 1.3， 因 此 有 一 个 文件 名 为 citext-- 
1.3.sql。 此 外 ， 还 有 用 来 从 一 个 版 本 转移 到 下 一 个 版 本 (1.0--1.1、1.1--1.2 等 ) 的 文件 。 
然后 还 有 一 个 .control 文件 : 


-bash-4.3$ cat citext.control 


# citext extension 

















comment = "data type for case-insensitive character strings' 
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default version = "1.3" 

module pathname = "$1libdir/citext" 

relocatable = true 

它 包 含 与 这 个 扩展 相关 的 所 有 元 数据 ， 第 一 项 包含 注释 ， 注 意 这 一 内 容 不 会 被 显示 
在 刚刚 讨论 过 的 系统 视图 中 。 当 用 户 访问 这 些 视 图 时 ，PostgreSQL 将 进入 这 个 目录 并 且 
读 取 所 有 的 .control 文件 ， 然 后 是 默认 版 本 和 二 进 制 文件 的 路 径 。 如 果 用 户 从 RPM 安装 一 
个 典型 的 扩展 ， 该 目录 将 会 是 $libdir， 它 位 于 用 户 的 PostgreSQL 二 进 制 目录 中 。 不 过 ， 
如 果 用 户 编写 了 自己 的 商业 扩展 ， 它 很 可 能 位 于 某 个 地 方 。 

最 后 一 个 设置 将 告诉 PostgreSQL 该 扩展 是 否 可 以 放 在 任意 一 个 方案 中 或 者 它 是 否 必 
须 放 在 一 个 固定 的 、 预 定义 的 方案 中 。 

最 后 ， 还 有 散装 文件 。 下 面 是 其 内 容 的 一 个 摘录 : 


ALTER EXTENSION citext ADD type citext; 

ALTER EXTENSION citext ADD function citextin(cstring); 
ALTER EXTENSION citext ADD function citextout (citext); 
ALTER EXTENSION citext ADD function citextrecv (internal); 


散装 文件 将 把 现 有 的 代码 转变 成 一 个 扩展 。 因 此 ， 有 必要 在 数据 库 中 整合 好 现 有 的 
东西 。 


11.2 利用 contrib 模块 





在 对 扩展 进行 了 理论 介绍 之 后 ， 接 下 来 看 看 一 些 最 重要 的 扩展 。 在 本 节 中 ， 读 者 将 了 
解 到 作为 PostgreSQL 的 contrib 模块 提供 给 用 户 的 模块 。 当 用 户 安装 PostgreSQL 时 ， 笔 者 
推荐 用 户 总 是 安装 那些 contrib 模块 ， 因 为 它们 包含 可 以 让 用 户 工 作 更 加 便利 的 重要 扩展 。 

在 本 节 中 ， 读 者 将 见识 到 其 中 一 些 笔 者 认为 最 有 趣 的 模块 。 


11.2.1 使 用 adminpack 


上 


adminpack 模块 的 想法 是 让 管理 员 可 以 不 通过 SSH 来 访问 文件 系统 。 这 个 包含 有 若干 
函数 让 这 种 访问 成 为 可 能 。 

为 了 把 该 模块 载 入 数据 库 ， 可 运行 下 面 的 命令 : 

test=# CREATE EXTENSION adminpack; 

CREATE EXTENSION 
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adminpack 模块 最 有 趣 的 特性 之 一 是 检查 日 志文 件 的 能 力 。pg_logdir ls 函数 检查 日 志 
目录 并 且 返 回 日 志文 件 的 列表 : 

test=# SELECT * FROM pg catalog.pg logdir 1s() RS (a timestamp, b text) 

ERROR: the log filename parameter must 














equal 'postgresql-%Y-%m-%d %H%M%S.1og" 


这 里 的 重点 是 log_filename 参数 必须 被 调整 为 adminspack 模块 所 需要 的 值 。 如 果 用 
户 正 好 运行 的 是 从 PostgreSQL 仓库 下 载 的 RPM，log_filename 参数 被 定义 为 postgresql- 
%a， 在 这 种 情况 下 它 就 需要 更 改 以 避免 错误 。 

在 更 改 后 ， 一 个 日 志文 件 名 的 列表 会 被 返回 : 

test=# SELECT * FROM pg catalog.pg logdir 1s() RS (a timestamp, b text) 

a 1 b 

Se TE 

2017-03-03 16:32:58 | pg_log/postgresql-2017-03-03_ 163258.1og 

(1 row) 


也 可 以 确定 磁盘 上 一 个 文件 的 尺寸 。 例 如 : 


test=# SELECT b, pg_catalog.pg file length(b) 
FROM pg_catalog.pg_ logdir 1s() AS (a timestamp, b text); 
b | pg_file length 
EE 二 二 三 
pg_log/postgresql-2017-03-03_163258.log | 1525 
(1 row) 


除 那些 特性 之 外 ， 该 模块 还 提供 了 更 多 函数 : 


test=# SELECT proname FROM pg_Proc WHERE Proname ~ "pg_ file .*'; 
proname 





pg_file write 
pg_file rename 
pg file unlink 
pg_file read 
pg_file length 


(5 rows) 


用 户 可 以 读 取 、 写 入 、 


ml 





命名 或 者 删除 文件 。 


人 那些 函数 当然 只 能 由 超级 用 户 调用 。 
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11.2.2 ”应 用 布 隆 过 滤器 


PostgreSQL 9.6 开始 可 以 使 用 扩展 ， 随 时 增加 索引 类 型 。 新 的 CREATE ACCESS 
METHOD 命令 以 及 一 些 额 外 的 特性 使 得 随时 增加 全 功能 且 被 事务 


为 可 能 





bloom 扩展 为 PostgreSQL 用 户 提 供 了 布 隆 过 滤器 ， 


快 地 减 小 数据 量 。 布 隆 过 滤器 的 思 
过 滤器 可 能 会 产生 一 些 伪 肯 定 但 是 仍然 能 极 大 地 降低 数据 量 。 
当 表 由 数 百 列 和 数 百 万 行 构成 时 ， 布 隆 过 滤器 就 特别 有 用 。 
引 数 百 列 ， 布 隆 过 滤器 是 一 种 很 好 的 替代 品 ， 























想 是 计算 一 





为 了 便于 展示 ， 笔 者 安装 了 该 扩展 : 


test=# CREATE EXTENSION bloom; 
CREATE EXTENSION 


下 一 步 ， 创 建 


test=# CREATE TABLE t bloom 


上 
id 
coll 
col2 
col3 
Col4 
col5 
col6 
Col7 
col8 
col9 

); 

CREATE TABLE 


为 了 让 例子 更 加 容易 操作 ， 那 些 列 都 有 一 个 默认 值 ， 这 样 可 以 使 用 


serial, 


int4 
int4 
int4 
int4 
int4 
int4 
int4 
int4 
int4 


SELECT 子 句 增加 数据 : 


test=# INSERT INTO t bloom (id) SELECT * 
1000000); 


FROM 


generate series(1, 


INSERT 0 1000000 


这 个 查询 把 一 百 万 行 加 入 该 表 中 。 


DEFAULT 
DEFAULT 
DEFAULT 
DEFAULT 
DEFAULT 
DEFAULT 
DEFAULT 
DEFAULT 
DEFAULT 


一 个 包含 很 多 列 的 表 : 


random () 
Fandom () 
random () 
random () 
random () 
random () 
Fandom () 
random () 
random () 


因为 它 允 许 一 次 索引 


1000， 
1000， 
1000， 
1000， 
1000， 
1000, 
1000, 
1000, 


1000 


它 是 一 种 预 




















预 滤器 ， 














现在 该 表 可 以 被 索引 : 


“DSS 


志 记 录 的 索引 类 型 成 


能 够 有 助 于 尽 
个 位 掩 码 并 且 把 位 掩 码 与 查询 对 比 。 布 隆 


1 于 不 可 能 用 B- 树 来 索 
所 有 的 东西 。 














个 简单 的 
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test=# CREATE INDEX idx bloom ON t bloom 
USING bloom(ceoll, CoOL27 COl3, coldy CO color col7lr cold, col9)s 
CREATE INDEX 


注意 该 索引 一 次 包含 了 9 列 。 与 B- 树 不 同 ， 那 些 列 的 顺序 实际 不 会 造成 区 别 。 注 意 
笔者 刚 创建 的 表 在 没有 索引 的 情况 下 大 约 为 65MB。 
索引 在 存储 占用 中 又 增加 了 另外 的 15MB。 


test=# \di+ idx bloom 





List of relations 


Schema | Name | Type | Owner | Table | Size | Description 
i ee 
public | idx bloom | index | hs 1 t bloom | 15 MB 

(1 row) 


布 隆 过 滤器 的 好 处 是 可 以 查找 列 的 任意 组 合 : 


test=# explain SELECT count (*) 
FROM 七 bloom 
WHERE col4 = 454 
AND col3 = 354 
AND col9 = 423; 


Aggregate (cost=20352.02..20352.03 rows=1 width=8) 
-> Bitmap Heap Scan on t bloom (cost=20348.00..20352.02 
rows=1 width=0) 
Recheck Cond: ((col3 = 354) AND (col4 = 454) AND (col9 = 423)) 
-> Bitmap Index Scan on idx bloom 
(cost=0.00. .20348.00 rows=1 width=0) 
Index Cond: ((col3 = 354) AND (col4 = 454) AND (col19 = 423) ) 
(5 rows) 


目前 我 们 所 看 到 的 效果 感觉 上 有 点 非 同 一 般 ， 那 么 很 自然 就 会 出 现 一 个 问题 ， 为 什 
么 不 总 是 使 用 布 隆 过 滤器 ? 原因 很 简单 一 一 为 了 使 用 布 隆 过 滤器 ， 数 据 库 必须 读 取 整个 
索引 。 而 在 B- 树 的 情况 中 则 不 必 如 此 。 

未 来 ， 很 可 能 将 会 加 入 更 多 的 索引 类 型 以 确保 PostgreSQL 能 够 覆盖 更 多 的 用 例 。 

如 果 读 者 想 要 阅读 更 多 有 关 布 隆 过 滤器 的 内 容 ， 可 以 考虑 阅读 我 们 的 博文 : 
http://www.cybertec.at/trying-out-postgres-bloom-indexes/。 
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11.2.3 部署 btree_gist 和 btree_gin 


在 这 一 小 节 有 关 索 引 的 简单 介绍 之 后 ， 会 有 更 多 索引 相关 的 特性 能 被 加 入 系统 中 。 
在 PostgreSQL 中 有 操作 符 类 的 概念 ， 它 们 已 经 在 第 5 章 中 讨论 过 。contrib 模块 提供 了 两 
个 扩展 〈 即 btree_gist 和 btree_gin〉 来 为 GiST 和 GIN 索引 增加 B- 树 功能 。 

为 什么 它们 这 么 有 用 ?GiST 索引 提供 了 多 种 B- 树 不 支持 的 特性 ， 其 中 之 一 是 执行 k 
近邻 (KNN) 搜索 的 能 

k 近邻 搜索 有 什么 用 呢 ? 想象 菜 人 在 查找 昨天 中 午 左右 增加 的 数据 ， 那 么 到 底 是 什 
么 时 候 ? 在 某 些 情况 下 可 能 很 难 给 出 界限 。 或 者 某 人 正在 查找 一 种 价格 大 约 70 欧元 的 产 
品 。KNN 就 可 以 解决 这 类 查询 。 下 面 是 一 个 例子 : 


test=# CREATE TABLE t test (id int); 
CREATE TABLE 


在 接 下 来 的 步骤 中 ， 一 些 简 单 的 数据 被 加 入 : 


test=# INSERT INTO 七 test SELECT * FROM generate series(1, 100000); 
INSERT 0 100000 


现在 可 以 增加 扩展 : 


test=# CREATE EXTENSION btree gist; 
CREATE EXTENSION 


为 列 增加 一 个 GiST 索引 很 容易 。 只 要 使 用 USING gist 子 句 就 好 。 注 意 在 一 个 整数 列 
上 增加 GiST 索引 只 有 在 已 经 加 入 了 该 扩展 时 才能 用 ， 否 则 ，PostgreSQL 将 报告 没有 合适 
的 操作 符 类 : 

test=# CREATE INDEX idx id ON t test USING gist(id); 

CREATE INDEX 


一 旦 索引 被 部 署 ， 就 可 以 用 距离 来 排序 : 


test=# SELECT * FROM t test ORDER BY id <-> 100 LIMIT 6; 
id 
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97 
(6 rows) 
如 你 所 见 ， 第 一 行 是 一 个 准确 匹配 ， 接 下 来 的 匹配 就 不 那么 精确 并 且 会 变 得 越 来 越 
糟 ， 这 个 查询 将 总 是 返回 固定 数量 的 行 。 
重点 是 其 执行 计划 : 
test=# explain SELECT * FROM t test ORDER BY id <-> 100 LIMIT 6; 
QUERY PLAN 





Limit (cost=0.28..0.64 rows=6 width=8) 
-> Index Only Scan using idx id on t test 
(cost=0.28..5968.28 rows=100000 width=8) 
Order By: (id <-> 100) 

(3 rows) 

如 你 所 见 ，PostgreSQL 直接 就 进行 了 索引 扫描 ， 这 显著 地 加 快 了 查询 的 速度 。 

在 PostgreSQL 的 未 来 版 本 中 ，B- 树 将 很 可 能 也 支持 KNN 搜索 。 在 开发 邮件 列表 中 
已 经 浮现 出 了 一 个 增加 这 种 特性 的 补丁 ， 也 许 它 最 终 将 出 现在 核心 中 。 让 B- 树 支持 KNN 
特性 将 最 终 导致 标准 数据 类 型 上 的 GiST 索引 变 少 。 


11.2.4 ”Dblink- 考 虑 逐步 淘汰 


使 用 数据 库 链 接 的 愿望 已 经 存在 了 很 多 年 。 不 过 ， 大 约 在 世纪 交替 时 PostgreSQL 的 
外 部 数据 包装 器 甚至 还 没有 初 现 端倪 ， 而 且 也 看 不 到 一 种 传统 的 数据 库 链 接 实 现 。 就 在 
这 个 时 间 段 ， 来 自 加 利 福 尼 亚 的 一 位 PostgreSQL 开发 者 (Joe Conway ) 通过 为 
PostgreSQL 引入 dblink 的 概念 推进 了 数据 库 连 通 性 上 的 工作 。 虽 然 dblink 很 好 地 为 人 们 
服务 了 很 多 年 ， 但 它 已 经 不 再 是 最 先进 的 技术 了 。 
忆 此 ， 推 荐 从 dblink 转 到 更 现代 化 的 SQL/MED 实现 〈 是 一 种 定义 外 部 数据 整合 到 关 
系数 据 库 中 方式 的 规范 ) 。postgres_fdw 扩展 已 经 在 SQL/MED 之 上 被 开发 出 来 ， 并 且 将 
提供 比 数据 库 连通 性 更 多 的 特性 ， 因 为 它 基本 上 人 允许 连接 到 任意 数据 源 。 


11.2.5 ”用 file_fdw 取得 文件 数据 


在 一 些 情 况 下 ， 有 必要 从 磁盘 读 取 文件 并 且 将 其 内 容 披露 给 PostgreSQL 作为 表 。 这 
一 点 正好 可 以 使 用 file fdw 扩展 实现 ， 其 思想 是 提供 一 个 模块 允许 用 户 从 磁盘 读 取 数 据 并 
且 使 用 SQL 对 其 进行 查询 。 
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首先 得 安装 该 模块 : 

CREATE EXTENSION file fdw; 

接 下 来 创建 一 台 虚 拟 服 务 器 : 

CREATE SERVER file server FOREIGN DATA WRAPPER file fdw; 

file_server 基于 file fdw 扩展 的 外 部 数据 包装 器 ， 它 会 告诉 PostgreSQL 如 何 访问 文件 。 
要 把 一 个 文件 作为 表 显示 ， 可 以 使 用 下 面 的 命令 : 


CREATE FOREIGN TABLE t passwd 
\ 


username text, 
passwd text, 
uid int; 
gid EnEs 
gecos text, 
dir text, 
shell text 


) SERVER file server 
OPTIONS (format 'text', filename '/etc/passwd', header 'false', delimiter':'); 


在 笔者 的 例子 中 ，/etc/passwd 文件 将 被 披露 出 来 。 所 有 的 域 都 必须 被 列 出 并 且 数 据 类 
型 必须 被 相应 地 映射 好 ， 所 有 额外 的 重要 信息 用 选项 传递 给 该 模块 。 在 这 个 例子 中 ， 
PostgreSQL 必须 了 解 文件 类 型 (text) 、 文 件 的 名 称 、 文 件 的 路 径 还 有 文件 内 容 使 用 的 定 
界 符 。 还 可 以 告诉 PostgreSQL 文件 中 是 否 有 头 部 。 如 果 该 设置 为 真 ， 第 一 行 就 是 不 重要 
的 ， 将 被 跳 过 。 如 果 用 户 正好 在 装载 一 个 CSV 文件 ， 跳 过 头 部 的 功能 就 特别 重要 。 

一 旦 表 被 创建 ， 就 可 以 读 取 数 据 : 


SELECT * FROM t passwd; 





不 出 意料 ，PostgreSQL 返回 了 /etc/passwd 的 内 容 : 


test=# \x 

Expanded display is on. 

test=# SELECT * FROM t passwd LIMIT 1; 
= RECORD TI 全 三 三 = 三 三 三 

username | root 

passwd es 

uid Lo 

gid bo 
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gecos | root 
dir | /root 
shell | /bin/bash 


在 查看 其 执行 计划 时 ， 读 者 将 看 到 PostgreSQL 使 用 了 外 部 扫描 来 从 该 文件 中 取得 数据 : 
test=# explain (verbose true, analyze true) 
SELECT * FROM t passwd; 
QUERY PLAN 


Foreign Scan on public.t passwd (cost=0.00..2.80 rows=18 width=168) 
(actual time=0.022..0.072 rows=61 loops=1) 
Output: username, passwd, uid, gid, gecos, dir, shell 
Foreign File: /etc/passwd 
Foreign File Size: 3484 
Planning time: 0.058 ms 
Execution time: 0.138 ms 
(6 rows) 


这 份 执 行 计划 还 告诉 我 们 文件 的 尺寸 等 信息 。 由 于 我 们 在 谈论 规划 器 ， 有 一 条 附注 
值得 一 提 : PostgreSQL 甚至 将 会 为 该 文件 取得 统计 信息 。 规 划 器 会 检查 文件 尺寸 并 且 会 
为 该 文件 设 定 与 同 尺寸 的 普通 PostgreSQL 表 相 同 的 代价 。 

11.2.6 使 用 pageinspect 检查 存储 

如 果 用 户 碰 到 存储 损坏 或 者 可 能 与 表 中 损坏 数据 块 相关 的 其 他 存储 问题 ，pageinspect 
扩展 可 能 是 用 户 所 需要 的 模块 : 


test=# CREATE EXTENSION pageinspect; 
CREATE EXTENSION 


pageinspect 的 想法 是 向 用 户 提 供 一 个 允许 在 二 进 制 级 别 检查 表 的 模块 。 
在 使 用 该 模块 时 ， 最 重要 的 事情 是 取得 一 块 : 


test=# SELECT * FROM get raw page('pg class', 0); 











这 个 函数 将 返回 单个 块 。 在 前 面 的 例子 中 ， 它 是 pg_class 参数 中 的 第 一 块 ，pg_class 
是 一 个 系统 表 〈 当 然 ， 可 以 使 用 任何 想 要 的 其 他 表 ) 。 
下 一 步 ， 可 以 抽取 页 面 的 头 部 : 
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test=# \x 
Expanded display is on. 
test=# SELECT * FROM page header(get raw page('pg class', 0)); 


-[ RECORD 1 ]--------- 
lsn 1/35CAE5B8 
checksum 0 

flags 和 

lower 240 

upper 1288 
special 8192 
pagesize 8192 
version 4 

prune xid 606562 





它 已 经 包含 了 很 多 有 关 该 页 面 的 信息 。 如 果 用 户 想 要 了 解 更 多 ， 可 以 调用 heap_page_ 
items 函数 ， 它 会 仔细 分 析 页 面 ， 并 且 为 其 中 的 每 个 元 组 返回 一 行 : 
test=# SELECT * 
FROM heap page items (get raw page('pg class', 0)) 


LIMIT 1; 
IRECORD dd = 
lp L 
lp_off 49 
lp_flags 2 
lp_len 0 
t xmin 
t xmax 
t_field3 
Le 


t infomask2 
t infomask 
t_ hoff 
EDEES 
tt Bid 
t _ data 


用 户 还 可 以 把 数据 分 成 多 个 元 组 : 


test=# SELECT tuple data split('pg class'::regclass, 
t data, t infomask, t infomask2, t bits) 





FROM heap page items(get raw page('pg class', 0)) 
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= EVD 1 ====1=====—==—====—====-======-====== 


tuple data split | 


OR 


tuple data split | 


{"\\x6100000000000000000000000000000000000000000000000000000000000000000000 
0000000000000000000000000000000000000000000000000000000000", "\\x98080000"," 
\\x50ac0c00", "\\x00000000", "\\x01400000", "\\x00000000", "\\x4eac0c00", "\\x00 
000000", "\\xbb010000", "\\x0050c347", "\\x00000000", "\\x00000000", "\\x01","\\ 
00" "NNxTOn, "NNx72", "NNXOTOO™, rNNXO000™, "\\x00™ "NNxOOn, "\\xO0n, "NNZO0m, nN 
Nx00", "\\x00", "\\x00", "\\x01", "\\x64", "\\xc3400900", "\\x01000000", NULL, NULL 


| 


为 了 阅读 这 些 数据 库 ， 用 户 必须 熟悉 PostgreSQL 的 磁盘 格式 ;否则 ， 数 据 可 能 会 显 


得 相当 星 涩 。 





pageinspect 为 所 有 访问 方法 〈 表 、 索 引 等 ) 提供 了 函数 并 且 允 许 详 细 地 分 析 存 储 。 
11.2.7 用 pg_buffercache 研究 缓冲 


在 简单 介绍 pageinspect 扩展 之 后 ， 笔 者 想 把 读者 的 注意 力 转 到 pg_buffercache 扩展 
上 ， 它 允许 用 户 深入 地 查看 其 IO 缓冲 的 内 容 : 


test=# CREATE EXTENSION pg buffercache; 


CREATE EXTENSION 


pg_buffercache 扩展 为 用 户 提 供 了 一 个 包含 若干 域 的 视图 : 


test=# \d pg_buffe 


rcache 


View "public.pg buffercache" 


Column 
bufferid 
relfilenode 
reltablespace 
reldatabase 
relforknumber 
relblocknumber 
isdirty 
usagecount 


pinning backends 


Type 


| integer 
| oid 

oid 

oid 
smallint 
bigint 
boolean 


smallint 





integer 


| Modifiers 
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bufferid 域 只 是 一 个 数字 ， 它 标识 缓冲 区 。 然 后 是 relfilenode 域 ， 它 指向 磁盘 上 的 文 
件 。 如 果 用 户 想 要 查看 一 个 文件 属于 哪个 表 ， 可 以 在 pg_class 系统 表 中 查找 ， 其 中 也 含 
有 一 个 relfilenode 域 。 接 下 来 还 有 reldatabase 和 reltablespace 域 。 注 意 所 有 的 域 都 被 定义 
为 oid 类 型 ， 因 此 为 了 能 以 更 有 用 的 方式 提取 数据 ， 有 必要 把 系统 表 连 接 起 来 。 

relforknumber 域 告诉 我 们 被 缓冲 的 是 该 表 的 哪 一 部 分 ， 它 可 能 是 堆 、 空 闲 空间 映射 
或 者 可 见 性 映射 之 类 的 某 种 其 他 部 件 。 未 来 肯定 将 会 有 更 多 类 型 的 关系 分 支 。 

接 下 来 的 relblocknumber 告诉 我 们 哪个 块 被 缓冲 。 最 后 有 isdirty 等 3 个 标志 ， 它 们 指 
示 块 已 经 被 修改 、 使 用 计数 器 以 及 对 块 加 pin 的 后 端 数量 。 

如 果 读 者 想 要 弄 明白 pg_buffercache 扩展 ， 有 必要 增加 额外 的 信息 。 假 定 用 户 想 要 弄 
清 哪 个 数据 库 使 用 缓冲 最 多 ， 下 面 的 查询 可 以 帮忙 ; 

test=# SELECT datname, Count (*) ， 

Count (*) FILTER (WHERE isdirty = true) AS dirty 
FROM pg_buffercache AS b, pg database AS d 
WHERE d.oid = b.reldatabase 
GROUP BY ROLLUP (1); 
datname | count | dirty 


Ee es 
abc i132 | 
postgres | 30 10 
test | 

L12137 0 SA 

(4 rows) 


T 


在 这 种 情况 下 ， 必 须 连接 pg_database 系统 表 。 如 你 所 见 ，oid 是 连接 条 件 ， 这 对 于 
PostgreSQL 的 新 手 来 说 可 能 不 是 那么 明显 。 
有 时 用 户 可 能 想 要 知道 所 连接 的 数据 库 中 哪些 块 被 缓冲 : 


test=# SELECT relname, relkind, 
count (*) ， 
Count (*) FILTER (WHERE isdirty = true) AS dirty 
FROM pg_buffercache AS b, pg database AS d, pg class AS c 
WHERE d.oid = b.reldatabase 
AND c.relfilenode = b.relfilenode 
AND datname = 'test" 
GROUP BY 1, 2 
ORDER BY 3 DESC 
LIMIT 7; 
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relname | relkind | count | dirty 
一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 十 一 一 一 一 一 一 一 一 一 十 一 一 一 一 一 一 一 十 一 一 一 一 一 一 一 
t bloom Es 1838338 "U0 
idx bloom Oe W620 
idx id Nn | 549 10 
t test Es | 445 1 0 
pg statistic 号 = 1 90 I 
pg_depend Ws 1 60 Wo 
pg_depend reference index | i 1 34 0 


(7 rows) 


这 种 情况 下 ， 笔 者 过 滤 出 当前 数据 库 并 且 与 pg_class 系统 表 连 接 ， 后 者 含有 对 象 的 
列表 。relkind 列 特别 值得 注意 : r 表示 表 (关系 ) 而 i 表示 索引 ， 它 将 告诉 用 户 正 在 查看 
哪 种 对 象 。 


11.2.8 用 pgcrypto 加 密 数 据 


在 整个 contrib 模块 小 节 中 最 强大 的 模块 之 一 就 是 pgcrypto， 它 最 初 由 Skype 的 一 位 
系统 管理 员 编写 并 且 提供 了 无 数 的 函数 来 加 密 和 解密 数据 。 

pgcrypto 为 对 称 以 及 非 对 称 加 密 提 供 了 函数 。 由 于 其 中 有 大 量 的 函数 ， 笔 者 推荐 查看 
其 文档 页 面 : https:/www.postgresql.org/docs/current/static/pgcrypto.html。 
1 于 本 章 的 篇 幅 有 限 ， 所 以 不 可 能 深入 pgcrypto 模块 的 所 有 细节 。 


11.2.9 用 pg_prewarm 预 热 缓冲 


在 PostgreSQL 正常 运作 时 ， 它 会 尝试 缓冲 重要 的 数据 。shared_buffers 变量 很 重要 ， 
因为 它 定义 了 PostgreSQL 所 管理 的 缓冲 的 大 小 。 现 在 的 问题 是 ， 如 果 用 户 重新 启动 数据 
库 服务 器 ， 所 有 由 PostgreSQL 管理 的 缓冲 内 容 都 将 丢失 。 可 能 操作 系统 还 将 有 一 些 数据 
以 减少 对 磁盘 的 影响 ， 但 是 在 很 多 情况 下 这 并 不 够 。 

对 这 个 问题 的 解决 方案 被 称 作 pg_prewarm 扩展 : 

test=# CREATE EXTENSION pg_ prewarm; 

CREATE EXTENSION 


该 扩展 部 署 一 个 函数 ， 它 允许 我 们 在 需要 时 显 式 地 预 热 缓冲 : 
test=# \x 

Expanded display is on. 

test=# \df *prewa* 


List of functions 
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RCoRDn 一 全 和 一 
Schema public 
Name pg_prewarm 


bigint 

regclass, mode text DEFAULT "buffer'::text， 
fork text DEFAULT ‘main'::text, 
first block bigint DEFAULT NULL::bigint, 
last block bigint DEFAULT NULL::bigint 


Result data type 


Argument data types 


Type | normal 
调用 pg_prewarm 扩展 最 简单 且 最 常用 的 方式 是 要 求 它 缓冲 一 整个 对 象 : 


test=# SELECT pg prewarm('t test') 7 
pg prewarm 


(1 row) 

注意 如 果 表 太 大 导致 无 法 完全 放 入 缓冲 ， 则 只 有 表 的 一 部 分 会 留 在 缓冲 中 ， 不 过 在 
大 部 分 情况 下 这 样 也 够 用 了 。 

该 函数 返回 被 函数 调用 处 理 的 8000 字 节 块 的 数量 。 

如 果 用 户 不 想 缓冲 一 个 对 象 的 所 有 块 ， 用 户 还 可 以 选择 表 中 一 个 指定 的 范围 。 在 接 
下 来 的 例子 中 ， 读 者 可 以 看 到 在 主 分 支 中 10 一 30 号 块 被 缓冲 : 

test=# SELECT pg prewarm('t test'， "buffer'， "main'"，10，30); 

pg prewarm 


(1 row) 


如 你 所 见 ， 有 21 个 块 被 缓冲 。 
11.2.10 用 pg_stat_statements 检查 性 能 














pg stat statements 是 contrib 模块 中 最 重要 的 模块 ， 应 该 总 是 被 启用 ， 它 能 够 为 用 户 
提供 更 好 的 性 能 数据 。 如 果 没 有 pg_stat_statements 模块 ， 确 实 很 难 追 踪 性 能 问题 。 
于 其 重要 性 ，pg_stat_statements 已 经 在 本 书 更 早 的 部 分 讨论 过 了 。 


11.2.11 用 pgstattuple 检查 存储 
有 时 候 会 发 生 PostgreSQL 中 的 表 过 分 增长 的 情况 ， 表 过 分 增长 的 技术 术语 是 表 膨 
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胀 。 现 在 出 现 的 问题 是 ， 哪 些 表 发 生 了 膨胀 以 及 有 多 大 程度 的 膨胀 ? pgstattuple 扩展 将 帮 
助 回答 这 些 问 题 : 


test=# CREATE EXTENSION pgstattuple; 
CREATE EXTENSION 


这 个 模块 同样 会 部 署 若干 函数 。 在 pgstattuple 扩展 中 ， 那 些 函 数 返回 一 个 由 一 种 组 合 
类 型 构成 的 行 。 因 此 ， 这 类 函数 必须 在 FROM 子 句 中 调用 以 确保 得 到 可 阅读 的 结果 : 
test=# \x 


Expanded display is on. 
test=# SELECT * FROM pgstattuple('t test'); 



































RECoBD ll 二 
table len | 3629056 
tuple count | 100000 
tuple len | 2800000 
tuple percent 1 77.16 
dead tuple count 0 

dead tuple len 0 

dead tuple percent | 0 
free_space | 16652 
free percent 1 0.46 


在 笔者 的 例子 中 ， 用 于 测试 的 表 看 起 来 处 于 一 种 相当 不 错 的 状态 ， 该 表 的 大 小 是 
3.6MB 并 且 不 包含 任何 死亡 的 行 ， 空 闲 空间 也 有 限 。 如 果 用 户 正在 受到 表 膨 胀 的 折磨 ， 
死亡 行 的 数量 和 空闲 空间 量 就 已 经 不 成 比例 地 增长 。 有 一 点 空闲 空间 和 少量 的 死亡 行 是 
正常 的 一 一 但 是 ， 如 果 表 已 经 过 分 增长 ， 那 么 它 大 部 分 会 由 死亡 行 和 空闲 空间 构成 ， 需 
要 采取 果断 的 行动 控制 住 局 面 。 

pgstattuple 扩展 也 提供 了 函数 来 检查 索引 : 


test=# CREATE INDEX idx id ON t test (id); 
CREATE INDEX 


pgstattindex 函数 返回 很 多 有 关 想 要 观察 的 索引 的 信息 : 


test=# SELECT * FROM pgstatindex('idx id'); 





EGORD I 9 
version Wg 
tree level We 
Tel > :hE | 2260992 


root block no I3 


internal _ pages 
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1 
leaf pages | 274 
empty pages IO 
deleted pages 1 个 
avg leaf density W8983 
leaf fragmentation | 0 





我 们 的 索引 相当 密集 (89%) 。 这 是 一 种 好 现象 。 索 引 的 默认 FILLFACTOR 设置 是 
90%， 因 此 接近 于 90% 的 值 都 表示 该 索引 处 于 非常 不 错 的 状态 。 








有 了 时候 上 








户 不 想 检查 单个 表 而 是 检查 一 个 方案 中 的 所 有 表 。 如 何 实现 这 种 要 求 ? 一 


般 来 说 ， 用 户 想 要 处 理 的 对 象 列表 应 该 在 FROM 子 句 中 。 不 过 在 笔者 的 例子 中 ， 函 数 已 
经 在 FROM 子 句 中 ， 那 么 我 们 怎么 让 PostgreSQL 在 表 的 列表 上 循环 呢 ? 答案 是 用 
LATERAL 连接 。 例 如 : 





test=# \x 

Expanded display is on. 

test=# SELECT tablename, (x).* 
FROM pg_ tables, 


LATERAL (SELECT * 
FROM pgstattuple (tablename)) AS x 


WHERE schemaname = "public'; 


= 二 RECORD' 1 J]====== 入 = 
tablename WESort 
table len | 114688 
tuple count | 2354 
tuple len 1 88686 
tuple percent ee 
dead tuple count 10 

dead tuple len 10 

dead tuple percent | 0 

ETFee Space 732 
free percent 1 6.74 


FROM 子 句 的 第 一 部 分 找到 我 们 要 查看 的 表 ， 每 一 个 被 返回 的 表 接 着 被 送 到 
LATERAL 连接 。 每 一 个 LATERAL 连接 都 可 以 被 视 作 一 个 for each 语句 。 

记 住 pgstattuple 必须 读 取 整 个 对 象 。 如 果 用 户 的 数据 库 很 大 ， 它 就 需要 很 长 的 时 间 进 
行 处 理 。 因 此 ， 将 已 经 看 到 的 查询 结果 保存 下 来 是 一 种 不 错 的 做 法 ， 这 样 就 可 以 仔细 地 
观察 结果 而 无 须 反 复 地 运行 这 种 查询 。 
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11.2.12 ”用 pg_trgm 进行 模糊 搜索 
pg_trgm 是 一 个 允许 用 户 执行 模糊 搜索 的 模块 ， 该 模块 已 经 在 第 3 章 讨论 过 。 
11.2.13 ”使 用 postgres_fdw 连接 到 远程 服务 器 


数据 并 不 总 是 只 在 一 个 位 置 上 ， 数 据 多 半 散 布 在 基础 设施 的 各 处 ， 而 且 有 可 能 发 生 











需要 将 位 于 多 个 位 置 的 数据 集成 起 来 的 需求 。 这 一 问题 的 解决 方案 是 由 SQL/MED 标准 定 


义 的 外 部 数据 包装 器 。 


在 本 节 中 将 讨论 postgres_fdw 扩展 ， 它 是 一 个 允许 用 户 动态 从 一 个 PostgreSQL 数据 


源 获 取 数据 的 模块 。 第 一 件 事情 是 部 署 外 部 数据 包装 器 ; 


test=# \h CREATE FOREIGN DATA WRAPPER 
Command: CREATE FOREIGN DATA WRAPPER 
Description: define a new foreign-data wrapper 
Syntax: 
CREATE FOREIGN DATA WRAPPER name 
[ HANDLER handler function | NO HANDLER ] 
[ VALIDATOR validator function | NO VALIDATOR ] 
[OPTIONS ( option value fs oe iT 


幸运 的 是 ，CREATE FOREIGN DATA WRAPPER 命令 被 隐藏 在 扩展 的 内 部 ， 它 可 以 


很 容易 地 使 用 正常 的 方式 安装 : 
test=# CREATE EXTENSION Postgres_fdw; 
CREATE EXTENSION 


下 一 步 必 须 定义 一 台 虚 拟 服务 器 ， 它 将 指向 其 他 主机 并 且 告 诉 PostgreSQL 从 哪 上 





到 数据 。 在 这 些 数据 的 末尾 ，PostgreSQL 还 必须 构建 一 个 完整 连接 字符 串 一 一 这 些 有 
器 数据 是 PostgreSQL 必须 了 解 的 第 一 类 信息 。 

接 下 来 将 增加 用 户 信息 。 服 务 器 将 只 包含 主机 、 端 口 等 信息 : 

test=# \h CREATE SERVER 

Command: CREATE SERVER 

Description: define a new foreign server 

Syntax: 


CREATE SERVER server name [ TYPE ‘server type' ] [ VERSION ‘server version'" 


] 
FOREIGN DATA WRAPPER fdw_ name 
INOPTIONS 0 optionl veloue le eo J 











= 
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为 了 便于 展示 ， 笔 者 在 同一 台 主机 上 创建 了 第 二 个 数据 库 并 且 创建 了 一 个 表 ”: 


[hs@zenbook ~]$ createdb customer 





[hs@zenbook ~]$ psql customer 

customer=# CREATE TABLE t customer (id int, name text); 
CREATE TABLE 

customer=# CREATE TABLE t company (country text, name text, active text); 
CREATE TABLE 

customer=# \d 

List of relations 

Schema | Name | Type | Owner 

一 -一 -一 一 一 一 十 一 一 一 一 一 一 一 一 一 一 一 一 十 一 一 一 一 一 一 一 十 一 一 一 一 一 一 一 

public | t company | table | hs 

public | t customer | table | hs 


(2 rows) 


现在 应 该 把 服务 器 加 入 标准 的 test 数据 库 中 : 


test=# CREATE SERVER customer server 

FOREIGN DATA WRAPPER postgres fdw 

OPTIONS (host '‘'localhost', dbname '‘'customer', port '5432'); 
CREATE SERVER 


注意 所 有 重要 的 信息 都 被 存储 为 OPTIONS 子 句 。 这 还 是 挺 重要 的 ， 因 为 它 为 用 户 提 


t 了 很 多 灵活 性 ， 不 同 的 外 部 数据 包装 器 将 需要 不 同 的 选项 。 


一 旦 服务 器 已 经 定义 好 ， 就 应 该 进行 用 户 映射 。 如 果 使 用 者 从 一 台 服 务 器 连接 到 其 


他 服务 器 ， 使 用 者 在 两 个 位 置 上 可 能 是 不 同 的 用 户 。 因 此 ， 外 部 数据 包装 器 要 求人 们 定 


义 实际 的 用 户 映 射 : 


test=# \h CREATE USER MAPPING 
Command: CREATE USER MAPPING 
Description: define a new mapping of a user to a foreign server 
Syntax: 
CREATE USER MAPPING FOR { user name | USER | CURRENT USER | PUBLIC } 
SERVER server name 
[IOPTIONS ( option "value® [>» -a. J Yl 


这 种 语法 相当 简单 并 且 很 容易 使 用 : 








原文 是 “一 台 服务 器 ”， 根 据 对 应 的 代码 判断 ， 这 里 应 该 是 笔 误 。 一 一 译 者 
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test=# CREATE USER MAPPING FOR CURRENT USER 
SERVER customer server 
OPTIONS (user 'hs', password ‘'abc'); 
CREATE USER MAPPING 


再 一 次 ， 所 有 重要 的 信息 都 隐藏 在 OPTIONS 子 句 中 。 根 据 外 部 数据 包装 器 的 类 型 ， 
选项 的 列表 也 将 不 同 。 

一 旦 基础 设施 就 位 ， 就 可 以 创建 外 部 表 。 创 建 外 部 表 的 语法 很 像 创 建 普通 本 地 表 的 
语法 。 所 有 的 列 都 必须 被 列 出 ， 包 括 它们 的 数据 类 型 : 


test=# CREATE FOREIGN TABLE f customer 





id nt, 
name text 


SERVER customer server 
OPTIONS (schema name 'public', table name 't customer'); 
CREATE FOREIGN TABLE 


所 有 列 就 像 在 普通 的 CREATE TABLE 子 句 中 那样 被 列 出 ， 特 别 之 处 在 于 外 部 表 指向 
一 个 位 于 远 端 的 表 。 方 案 的 名 称 和 远 端 表 的 名 称 必须 在 OPTIONS 子 句 中 被 指定 。 
外 部 表 被 创建 好 后 就 可 以 使 用 了 : 


test=# SELECT * FROM f customer ; 
id | name 
Ee 


(0 rows) 
要 查看 PostgreSQL 内 部 做 的 事情 ， 运 行 带 有 analyze 参数 的 EXPLAIN 子 句 是 一 种 好 
办 法 。 它 将 揭示 服务 器 中 到 底 在 做 些 什么 : 


test=# EXPLAIN (analyze true, verbose true) 
SELECT * FROM f customer ; 
QUERY PLAN 


Foreign Scan on public.f customer 
(cost=100.00..150.95 rows=1365 width=36) 
(actual time=0.221..0.221 rows=0 loops=1) 
Output: id, name 
Remote SQL: SELECT id, name FROM public.t customer 
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Planning time: 0.067 ms 
Execution time: 0.451 ms 


(5 rows) 


这 里 很 重要 的 部 分 是 Remote SQL。 外 部 数据 包装 器 将 发 送 一 个 查询 到 另 一 端 并 且 取 
得 尽 可 能 小 的 数据 。 在 远 端 会 执行 尽 可 能 多 的 限制 以 确保 不 会 有 太 多 数据 需要 被 拿 回 到 
本 地 处 理 。 过 滤 条 件 、 连 接 甚至 聚集 都 可 以 被 在 远程 执行 (从 PostgreSQL 10.0 开始) 。 

虽然 CREATE FOREIGN TABLE 子 句 确实 是 一 种 很 好 用 的 东西 ， 但 是 一 次 又 一 次 地 
列 出 所 有 那些 列 也 很 麻烦 。 

这 个 问题 的 解决 方案 被 称 为 IMPORT 子 句 。 它 允许 用 户 快速 简便 地 把 整个 方案 导入 
用 户 的 本 地 数据 库 中 并 且 创建 外 部 表 : 

test=# \h IMPORT 


Command: IMPORT FOREIGN SCHEMA 
Description: import table definitions from a foreign server 














Syntax: 
IMPORT FOREIGN SCHEMA remote schema 
LIMIT TOMEXCRPT (table name Le -= SI] 


FROM SERVER server name 
INTO local schema 
[ OPTIONS ( option "value’ [sr =-。 1] ) |] 


IMPORT 允许 用 户 简便 地 链接 到 大 型 的 表 集 合 。 它 还 能 减少 出 现 拼 写 和 输入 错误 的 
概率 ， 因 为 所 有 的 信息 都 直接 从 远程 数据 源 取 得 。 


test=# IMPORT FOREIGN SCHEMA public 
FROM SERVER customer server 
INTO public; 

IMPORT FOREIGN SCHEMA 


在 这 个 例子 中 ， 所 有 以 前 在 public 模式 中 创建 的 表 都 被 直接 链接 进来 。 如 你 所 见 ， 
现在 所 有 的 远程 表 都 可 用 了 : 


test=# \det 
List of foreign tables 
Schema | Table 1 Server 


public 


public | f customer | customer server 
| t company | customer server 
| 


public t customer | customer server 


(3 rows) 
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@ 处理 错误 

创建 外 部 表 实 际 并 不 难 一 一 但 是 ， 有 时 候 人 们 会 犯错 ， 或 者 口令 被 更 改 了 。 为 了 处 
理 这 类 问题 ，PostgreSQL 提供 了 两 个 命令 。 

ALTER SERVER 人 允许 用 户 修改 服务 器 : 

test=# \h ALTER SERVER 


Command: ALTER SERVER 
Description: change the definition of a foreign server 


Syntax: 
ALTER SERVER name [ VERSION 'new version' ] 
[ OPTIONS ( [ ADD | SET | DROP ] option ['value'] [, ... ] ) ] 


ALTER SERVER name OWNER TO { new owner | CURRENT USER | SESSION USER } 
ALTER SERVER name RENAME TO new name 


用 户 可 以 使 用 这 个 命令 为 一 台 特 定 的 服务 器 增加 以 及 移 除 选项 ， 在 用 户 遗 忘 了 某 些 
事情 的 情况 下 这 个 命令 很 有 用 。 
如 果 使 用 者 想 要 修改 用 户 信息 ， 使 用 者 也 可 以 修改 用 户 映射 : 
test=# \h ALTER USER MAPPING 
Command: ALTER USER MAPPING 
Description: change the definition of a user mapping 
Syntax: 
ALTER USER MAPPING FOR { user name | USER | CURRENT USER | SESSION USER | 
PUBLIC } 
SERVER server name 
OPTIONS ( [ ADD | SET | DROP ] option ['value’'] [, ... ] ) 


SQL/MED 接口 会 被 定期 地 改进 ， 并 且 就 在 读者 阅读 本 书 时 新 的 特性 也 在 加 入 。 在 未 
来 ， 更 多 地 优化 将 被 放 入 核心 中 ， 使 得 SQL/MED 接口 成 为 改进 可 扩展 性 的 一 种 很 好 的 

















11.3 其 他 有 用 的 扩展 


到 目前 为 止 ， 所 描述 的 扩展 都 是 PostgreSQL 的 contrib 包 的 组 成 部 分 。 但 是 ， 读 者 
已 经 看 到 的 包 并 非 PostgreSQL 社区 中 唯一 可 用 的 包 ， 还 有 更 多 包 人 允许 使 用 者 做 各 种 各 样 
的 事情 。 

可 惜 本 章 的 篇 幅 太 短 ， 我 们 没有 办 法 深入 所 有 扩展 中 。 模 块 的 数量 每 天 都 在 增加 ， 所 
以 本 书 也 不 可 能 涵盖 到 所 有 的 内 容 。 因 此 ， 笔 者 只 想 点 出 自己 认为 最 重要 的 那些 扩展 。 
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PostGIS (http://postgis.net/) 是 开源 世界 中 的 地 理 信息 系统 (GIS)〉 数据 库 接 口 ， 它 
已 经 在 全 球 很 多 应 用 中 被 采用 并 且 是 关系 型 开源 数据 库 世 界 中 的 事实 标准 ， 它 是 一 种 专 
业 而 且 极 强大 的 解决 方案 。 

如 果 使 用 者 正在 查找 地 理 空间 路 径 ，pgRouting 就 是 使 用 者 可 能 在 寻找 的 工具 。 它 提 
t 了 多 种 算法 来 寻找 位 置 之 间 的 最 佳 连 接 并 且 可 以 在 PostgreSQL 之 上 工作 。 

在 本 章 中 ， 读 者 已 经 学 到 了 postgres fdw 扩展 ， 它 允许 使 用 者 连接 到 某 个 其 他 的 
PostgreSQL 数据 库 。 还 有 更 多 的 外 部 数据 包装 器 存在 ， 其 中 一 个 最 著名 且 最 专业 的 是 
oracle_ fdw 扩展 。 它 允许 使 用 者 与 Oracle 进行 集成 并 且 通 过 网 络 从 Oracle 中 取得 数据 ， 
就 好 像 用 postgres_fdw 扩展 所 作 的 事情 那样 。 























ps 




















11.4 总 结 


在 本 章 中 ， 读 者 学 到 了 一 些 最 有 前 途 的 包含 在 PostgreSQL 标准 发 布 中 的 模块 。 这 些 
模块 非常 多 样 ， 包 括 了 从 数据 库 连 通 性 到 大 小 写 不 敏感 文本 以 及 检查 服务 器 的 模块 。 在 
介绍 完 扩 展 之 后 ， 笔 者 将 会 把 读者 注意 力 转移 到 迁移 上 。 读 者 将 学 到 如 何以 最 简单 的 方 
式 转移 到 PostgreSQL 上 。 


第 12 章 在 PostgreSQL 中 排查 错误 


在 本 书 的 第 11 章 中 ， 读 者 学 到 了 一 些 被 广泛 采用 的 扩展 ， 它 们 对 用 户 的 部 署 是 有 力 
的 促进 。 接 下 来 ， 本 书 将 向 读者 介绍 PostgreSQL 的 故障 排除 。 主 要 想法 是 给 读者 一 种 系 
统 的 方法 检查 并 且 修 复 其 系统 。 

本 章 将 关注 下 列 主题 : 





处 理 未 知 的 数据 库 。 
获得 一 份 简要 概述 。 
确定 关键 的 瓶颈 。 

处 理 存储 损坏 。 

检查 坏 掉 的 复制 系统 。 


要 记 住 很 多 事情 都 可 能 会 出 错 ， 因 此 有 必要 专业 地 监控 数据 库 。 


12.1 着 手 处 理 一 个 陌生 的 数据 库 


如 果 用 户 恰好 管理 着 一 个 大 规模 系统 ， 他 /她 可 能 不 知道 系统 到 底 在 做 什么 。 管 理 数 
百 个 系统 则 意味 着 用 户 将 无 法 了 解 在 每 个 系统 中 正在 发 生 的 事情 。 


在 排查 故障 时 ， 最 重要 的 事情 可 以 归结 成 一 个 词 
就 没有 办 法 修复 问题 。 因 此 ， 排 查 故障 的 第 一 步 总 是 设置 一 种 pgwatch2 之 类 的 监控 工 





数据 。 如 果 没 有 足够 的 数据 ， 





具 ， 它 们 能 让 用 户 洞悉 其 数据 库 服务 器 内 部 。 
一 旦 从 报告 中 发 现 值得 检查 的 情况 ， 就 意味 着 这 种 有 条 理 地 着 手 处 理 该 系统 的 方式 
发 挥 了 作用 。 


12.2 检查 pg_stat_activity 


笔者 推荐 的 第 一 件 事情 是 检查 pg_stat_activity?。 回 答 下 列 问 题 : 





当前 有 多 少 并 发 事务 在 你 的 系统 中 运行 ? 
是 否 总 是 在 query 列 中 看 到 类 似 的 查询 类 型 ? 
有 没有 看 到 已 经 运行 了 很 长 时 间 的 查询 ? 





原文 是 “pg_stat_statements”， 但 根据 上 下 文 的 意思 ， 应 该 是 笔 误 ， 正 确 应 为 “pg_stat_activity”。 一 一 译 者 
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@ ”有 没有 没有 被 授予 的 锁 ? 

@ 是否 看 到 来 自 可 疑 主机 的 连接 ? 

应 该 总 是 首先 检查 pg_stat_activity 视图 ， 因 为 它 反映 了 系统 中 正在 发 生 什么 事情 。 当 
然 ， 图 形 化 监控 也 能 让 用 户 对 系统 形成 第 一 印象 。 但 是 ， 最 终 还 是 要 归结 到 实际 运行 在 
服务 器 上 的 查询 。 因 此 ， 由 pg _stat activity 提供 的 好 的 系统 概述 比 查 出 问题 更 加 关键 。 

为 了 便于 读者 使 用 ， 笔 者 已 经 编写 了 若干 查询 ， 笔 者 认为 它们 有 助 于 尽快 找到 问题 。 

@ 查询 pg _stat_activity 

下 面 的 查询 展示 在 数据 库 中 当前 正在 执行 多 少 查询 : 

test=# SELECT datname, 

Count (*) RS open, 
Count (*) FILTER (WHERE state "active') RS active， 
Count (*) FILTER (WHERE state "idle') AS idle, 


count (*) FILTER (WHERE state = 'idle in transaction') RS 
idle in trans 






































FROM pg stat activity 
GROUP BY ROLLUP(1); 
datname | open | active 


1 
-一 -一 -一 一 十 一 一 一 一 一 一 十 一 一 一 一 一 一 一 一 十 一 一 一 一 一 一 十 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 
dev | EW | Ll 0 1 0 
test 1 过 | el 0 1 
| 3 | 0 1 1 
(3 rows) 


为 了 在 同一 屏 上 显示 尽 可 能 多 的 信息 ， 这 个 查询 中 使 用 了 部 分 聚集 。 读 者 可 以 看 到 
active、idle 以 及 idle in transaction 的 查询 。 如 果 看 到 大 量 “idle in transaction” 查 询 ， 绝 对 
有 必要 深究 一 下 那些 事务 已 经 打开 了 多 久 : 

test=# SELECT pid, xact start, now() - xact start AS duration 

FROM py statiactivity 


WHERE state LIKE '%transaction%s" 
ORDER BY 3 DESC; 


pid | xact_ start 1 duration 
i TT 
22503 小 2017=03=15 13:13508.368974+01 1 22:14:12.126463 
(1 row) 


列表 中 的 事务 已 经 被 打开 了 超过 22 小 时 。 现 在 的 主要 问题 是 ， 为 什么 一 个 事务 可 以 
被 打开 那么 久 ? 在 大 部 分 应 用 中 ， 耗 费 如 此 长 时 间 的 事务 非常 可 疑 并 且 有 可 能 极度 危 
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险 。 然 而 ， 危 险 来 自 何 处 ?正如 读者 在 本 书 中 已 经 了 解 的 ，VACUUM 子 句 只 能 清理 那些 
不 再 对 任 一 事务 可 见 的 死亡 行 。 现 在 ， 如 果 一 个 事务 保持 打开 状态 数 小 时 甚至 数 天 ， 
VACUUM 子 句 就 无 法 产生 有 用 的 结果 ， 最 终 将 会 导致 表 膨 胀 。 
寻 此 ， 笔 者 高 度 推 荐 确保 长 事务 都 处 于 监控 之 下 ， 或 者 在 运行 太 久 的 情况 下 杀 死 它 
们 。 从 版 本 9.6 开始 ，PostgreSQL 有 了 一 种 称 为 “snapshot too old” 的 特性 ， 这 人 允许 用 户 
在 快照 存在 过 久 的 情况 下 中 止 长 事务 。 
还 有 一 种 好 的 方法 是 检查 是 否 有 长 查询 运行 : 
test=# SELECT now() - query start AS duration, datname, query 
FROM pg stat activity 
WHERE state = "active'" 
ORDER BY 1 DESC; 


























duration | datname | query 
a RN RE Ee Ns RS PS 
00:00:38.814526 | dev | SELECT pg sleep(10000); 
00:00:00 | test | SELECT now() - query start AS duration, 


datname, query FROM pg stat activity WHERE 
state = "active' ORDER BY 1 DESC; 
(2 rows) 
在 这 种 情况 下 ， 会 得 到 所 有 的 活动 查询 ， 并 且 该 语句 会 计算 一 个 查询 已 经 活动 了 多 
久 。 用 户 经 常会 看 到 相似 的 查询 出 现在 顶部 ， 它 们 能 给 出 一 些 有 关于 系统 中 正在 发 生 什 
么 的 线索 。 


1， 处 理 Hibernate 语句 


很 多 ORM (例如 Hibernate) 会 产生 疯狂 的 长 SQL 语句 。 这 会 带 来 一 个 小 问题 ， 
pg_stat_activity 将 只 在 系统 视图 中 存放 查询 的 前 1024 字 节 ， 剩 下 的 部 分 都 会 被 截 去 。 对 
于 Hibernate 之 类 ORM 生成 的 长 查询 来 说 ， 查 询 可 能 在 有 趣 的 部 分 (FROM 子 句 等 ) 开 
始 之 前 就 被 切断 了 。 

这 一 问题 的 解决 方案 是 在 postgresql.conf 文件 中 设置 一 个 config 参数 : 

test=# SHOW track activity query size; 


track activity query size 


将 这 个 参数 调 高 到 合理 的 值 ( 可 能 是 32768) 并 且 重 启 PostgreSQL。 用 户 将 能 看 到 
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长 很 多 的 查询 并 且 能 够 更 容易 地 检测 出 问题 。 
2 确定 查询 的 来 源 
在 观察 pg_stat_activity 时 ， 有 一 些 域 将 会 告诉 用 户 查询 来 自 哪里 : 





client addr leinet 
client hostname | text 
client port | integer 


那些 域 将 包含 人 P 地 址 和 主机 名 如果 配 置 ) 。 但 是 ， 如 果 所 有 的 应 用 都 位 于 同一 台 
应 用 服务 器 上 ， 就 会 导致 它们 都 从 完全 相同 的 IP 发 送 其 查询 ， 那 么 会 发 生 什么 ? 用 户 很 
难 知道 一 个 特定 的 查询 到 底 由 哪个 应 用 生成 。 
这 类 问题 的 解决 方案 是 要 求 开发 者 设置 一 个 application_name 变量 : 
test=# SHOW application name ; 
application name 




















test=# SET application name TO 'some name'; 
SET 

test=# SHOW application name ; 

application name 


some_name 
(1 row) 


如 果 人 们 都 合作 ，application_name 变量 将 会 出 现在 该 系统 视图 中 ， 这 样 就 更 容易 看 
到 查询 从 哪里 来 。application_name 变量 也 可 以 被 作为 连接 字符 串 的 一 部 分 进行 设置 。 


12.3 ”检查 慢 查 询 


在 检查 了 pg_stat_activity 之 后 ， 有 必要 看 一 看 慢 的 、 很 消耗 时 间 的 查询 。 基 本 上 有 两 
种 方法 来 解决 该 问题 : 

@ 在 日 志 中 查找 个 别 的 慢 查 询 。 

@ 查找 花费 太 多 时 间 的 查询 类 型 。 

寻找 单个 慢 查 询 是 经 典 的 性 能 调 优 方法 。 通 过 设置 log_min_duration_statement 变量 
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为 一 个 期 望 的 阔 值 ，PostgreSQL 将 开始 为 每 个 超过 该 阔 值 的 查询 在 日 志 中 记 下 一 行 。 慢 
查询 日 志 默 认 被 关闭 : 
test=# SHOW log _ min duration statement; 
log min duration statement 


= 

(1 row) 

不 过 ， 把 这 个 变量 设置 为 一 个 合理 的 值 非常 重要 。 根 据 用 户 的 负载 ， 期 望 的 时 间 当 
然 会 发 生变 化 。 








在 很 多 情况 下 ， 每 个 数据 库 的 这 个 期 望 值 可 能 都 不 同 。 因 此 ， 也 可 以 以 更 细 的 粒度 
使 用 这 个 变量 : 
test=# ALTER DATABASE test 


SET log min duration statement TO 10000; 
ALTER DATABASE 


如 果 用 户 的 数据 库 面 临 着 不 同 的 负载 ， 那 么 只 为 特定 的 数据 库 设 置 这 个 参数 就 非常 
有 必要 。 

在 使 用 慢 查 询 日 志 时 ， 有 必要 考虑 一 个 重要 的 因素 一 一 很 多 较 小 的 查询 可 能 导致 比 
一 小 部 分 慢 查询 更 多 的 负载 。 当 然 ， 察 觉 到 慢 查 询 个 体 总 是 有 必要 的 ， 但 是 有 时 候 这 些 
查询 并 不 是 问题 。 考 虑 下 面 的 例子 : 在 用 户 的 系统 上 ，1 百 万 个 花费 500 毫秒 的 查询 与 一 
些 运 行 数 分 钟 的 分 析 查 询 一 起 执行 。 显 然 ， 实 际 的 问题 将 不 会 出 现在 慢 查询 日 志 中 ， 而 
每 一 次 数据 导出 、 每 一 次 索引 创建 以 及 每 一 次 批量 装载 (这 些 工作 在 大 部 分 情况 下 都 无 
法 避免 ) 将 会 在 日 志 中 经 常 出 现 并 且 把 用 户 导 向 错误 的 方向 。 

因此 ， 笔 者 的 个 人 建议 是 慢 查询 日 志 有 必要 使 用 ， 但 是 要 小 心地 使 用 。 而 且 最 重要 
的 是 ， 要 意识 到 通过 慢 查 询 日 志 到 底 要 发 现 什么 。 

在 笔者 看 来 ， 更 好 的 方法 是 更 紧密 地 结合 pg_stat statements 变量 的 使 用 。 它 将 提供 
聚合 信息 而 不 仅 是 单个 查询 的 信息 。 在 本 书 稍 早 的 部 分 已 经 讨论 过 pg_stat_statements 变 
量 ， 但 该 模块 的 重要 性 再 怎么 强调 也 不 为 过 。 


12.3.1 检查 个 体 查 询 


有 时 ， 可 以 确定 慢 查 询 ， 但 用 户 仍然 没有 有 关 问 题 真相 的 线索 。 当 然 ， 下 一 步 是 检 
查 该 查询 的 执行 计划 并 且 看 看 发 生 了 什么 。 要 在 计划 中 找 出 对 糟糕 运行 时 间 负 有 责任 的 
那些 关键 操作 相当 简单 。 尝 试 使 用 下 面 的 检查 表 : 
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@ ”尝试 查看 计划 中 什么 地 方 时 间 开 始 飞 涨 。 

检查 缺失 的 索引 糟糕 性 能 的 主要 原因 之 一 )。 

@ 使 用 EXPLAIN 子 句 (buffers true、analyze true 等 ) 来 看 看 查询 是 否 用 了 太 多 组 
冲 区 。 

@ 打开 track io timing 参数 以 找 出 是 否 有 IO 问题 或 者 CPU 问题 (明确 检查 是 否 
有 随机 IO 进行 ) 。 

@ 查找 错误 的 估计 并 且 尝 试 修复 。 

@ 查找 被 过 于 频繁 执行 的 存储 过 程 。 

@ 如果 有 这 样 的 存储 过 程 ， 看 看 其 中 是 否 有 一 些 可 以 被 标记 为 STABLE 或 者 
IMMUTABLE。 

注意 ，pg_stat_statements 没有 把 解析 时 间 计 算 在 内 ， 因 此 如 果 用 户 的 查询 非常 长 ( 查 

询 字符 串 ) ，pg_stat_statements 可 能 会 有 一 点 误导 性 。 


12.3.2 用 perf 深入 研究 


在 大 部 分 情况 下 ， 做 完 这 个 小 的 检查 表 将 帮助 用 户 以 非常 快速 且 有 效 的 方式 查 出 主 
要 的 问题 。 但 是 ， 即 便 从 数据 库 引擎 提取 的 信息 有 时 候 也 不 够 。 

perf 是 一 种 用 于 Linux 的 分 析 工 具 ， 它 允许 用 户 直 接 查 看 哪些 C 函数 导致 了 用 户 系统 
上 的 问题 。 通 常 perf 默认 没有 被 安装 ， 因 此 推荐 安装 它 。 要 在 服务 器 上 使 用 perf， 只 需 
要 以 root 权限 登录 并 且 运 行 : 

perf top 

每 隔 若 干 秒 屏幕 将 会 自动 刷新 ， 用 户 将 有 机 会 可 以 看 到 有 哪些 活动 正在 进行 。 接 下 
来 的 列表 展示 了 一 个 标准 的 只 读 测试 基准 的 模样 : 


Samples: 164K of event ‘cycles:ppp', Event count (approx.): 109789128766 

















Overhead Shared Object Symbol 
3.10% postgres [.] AllocSetAlloc 
1.99% postgres [.] SearchCatCache 
1.51% postgres [.] base yyparse 
T4423 postgres [.] hash search with hash value 
Le 1D 2 [.] vfprintf 
113% 11ibec=2.:22:30 [:] jint malloc 
0.87% postgres Cl palloc 
0.74% postgres [.] MemoryContextAllocZeroAligned 
066% Jibc 2:22.30 Ls strcmp sse2 unaligned 
0.66% [kernel] [k] raw spin lock irqsave 
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0.66% postgres [.] bt compare 
0.63% [kernell] [k] _ fget light 
O02% Jibc=2.22.30 [.] strlen 
可 以 看 到 在 我 们 的 例子 中 没有 单个 函数 占用 过 多 的 CPU 时 间 ， 这 告诉 我 们 系统 状态 


挺 好 。 

但 情况 并 非 总 是 这 样 。 有 一 种 非常 常见 的 问题 ， 被 称 为 自 旋 锁 竞争 。 那 是 什么 ? 自 
旋 锁 (https:/en.wikipedia.org/wiki/Spinlock) 被 PostgreSQL 核心 用 来 同步 诸如 缓冲 区 访问 
之 类 的 事情 。 自 旋 锁 是 现代 CPU 提供 的 一 种 特性 ， 它 被 用 来 避免 操作 系统 对 于 小 型 操作 
〈 例 如 增加 一 个 数字 ) 的 交互 作用 。 它 是 一 种 好 东西 ， 但 是 在 一 些 非常 特殊 的 情况 下 ， 
自 旋 锁 可 能 变 得 很 古怪 。 如 果 用 户 正 面临 着 自 旋 锁 竞争 ， 其 现象 如 下 : 

@ 非常 高 的 CPU 负载 。 

@ 难以 置信 的 低 吞 吐 〈 通 常 花费 数 毫秒 的 查询 突然 需要 花费 数秒 ) 。 

@ JIO 通常 很 低 ， 因 为 CPU 在 忙于 交易 锁 。 

在 很 多 情况 下 ， 自 旋 锁 竞争 都 是 突然 发 生 的 。 用 户 的 系统 本 来 好 好 的 ， 突 然 负 载 暴 
增 而 吞吐 直线 下 降 。perf top 命令 将 会 显示 大 部 分 的 时 间 被 花费 在 一 个 名 为 s lock 的 C 函 
数 中 。 如 果 情 况 就 是 这 样 ， 用 户 应 该 尝试 下 面 的 办 法 : 


huge pages = try ony orf rery 


将 huge_pages 从 try 改 成 off。 在 操作 系统 级 别 也 一 同 关闭 大 页 特性 可 能 是 一 个 好 3 
意 。 通 常 ， 似 乎 一 些 内 核 比 其 他 的 内 核 更 倾向 于 产生 这 类 问题 。Red Hat 2.6.32 系列 似乎 
尤其 糟糕 (注意 笔者 用 的 是 “似乎 ”) 。 

如 果 用 户 在 使 用 PostGIS，perf 也 非常 有 吸引 力 。 如 果 列 表 中 顶部 的 函数 都 是 GIS 相 
关 的 《一 些 底层 库 ) ， 用 户 应 该 认识 到 问题 不 太 可 能 来 自 于 不 好 的 PostgreSQL 调 优 ， 只 
是 因为 执行 了 需要 花费 很 多 时 间 完 成 的 昂贵 操作 而 已 。 











mr 


12.4 检查 日 志 





如 果 系 统 出 现 了 问题 的 征兆 ， 有 必要 检查 日 志 看 看 发 生 了 什么 。 这 里 的 重点 是 ， 并 
非 所 有 的 日 志 项 都 是 被 平等 创建 的 。PostgreSQL 采用 了 一 种 日 志 项 的 层级 结构 ， 其 范围 
从 DEBUG 消息 一 直到 PANIC 消息 。 

对 于 管理 员 来 说 ， 下 面 3 种 错误 级 别 的 重要 性 很 高 : 

© FERROR 

© FATAL 

®© PANIC 
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ERROR 被 用 于 语法 错误 、 权 限 相关 错误 等 问题 。 用 户 的 日 志 将 总 是 包含 错误 消息 。 
关键 问题 是 ， 一 种 特定 错误 类 型 出 现 的 频率 如 何 ? 产生 上 百 万 的 语法 错误 显然 不 是 运行 
数据 库 服务 器 的 理想 方式 。 

FATAL 比 ERROR 更 加 可 怕 ， 例 如 无 法 为 共享 内 存 名 称 分 配 内 存 时 或 者 出 现 意外 的 
walreceiver 状态 时 都 将 看 到 FATAL 消息 。 换 种 说 法 ， 这 类 错误 消息 已 经 极其 吓人 了 ， 它 
们 将 告诉 用 户 系统 中 出 现 了 问题 。 

最 后 是 PANIC。 如 果 用 户 碰 到 了 这 种 消息 ， 那 么 就 说 明 数 据 库 系统 真 出 现 了 问题 。 
PANIC 的 典型 例子 就 是 锁 表 损坏 或 者 创建 了 太 多 信号 量 。 这 种 消息 将 会 导致 停机 。 


12.5 ”检查 缺失 的 索引 











一 旦 做 完了 前 3 个 步骤 ， 就 有 必要 从 总 体 上 来 看 看 系统 的 性 能 。 正 如 笔者 在 本 书 中 
反复 提 到 的 ， 索 引 缺 失 是 造成 性 能 不 好 非常 重要 的 原因 。 因 此 ， 只 要 碰 到 一 个 很 慢 的 系 
统 ， 推 荐 检查 有 没有 索引 缺失 并 且 部 署 所 需要 的 索引 。 

通常 客户 会 要 求 我 们 优化 RAID 级 别 、 调 优 内 核 或 者 做 其 他 一 些 花 俏 的 事情 。 实 际 
上 ， 那 些 复杂 的 请 求 常常 会 归结 为 少量 缺失 的 索引 。 笔 者 认为 ， 总 是 有 必要 花 一 些 额外 
的 时 间 来 检查 是 否 想 要 的 索引 都 已 经 被 创建 。 检 查 索引 缺失 既 不 困难 也 花 不 了 多 少时 
间 ， 所 以 不 管 面临 着 何 种 性 能 问题 ， 都 应 该 做 这 种 检查 。 

下 面 是 笔者 最 喜欢 的 查询 ， 它 可 以 让 我 们 形成 哪里 可 能 缺少 索引 的 印象 : 

SELECT schemaname, relname, seq scan, seq tup read, 

idx scan, seq tup read / seq scan AS avg 

FROM pg_stat user tables 

WHERE seq scan > 0 

ORDER BY seq tup read DESC 

ME 人 从 


这 个 查询 尝试 查找 经 常 被 扫描 的 大 型 表 (avg 高 ) ， 那 些 表 将 出 现在 结果 的 顶部 。 
12.6 检查 内 存 和 IO 


做 完 缺 失 索 引 的 查找 检查 之 后 ， 接 下 来 可 以 检查 内 存 和 VO。 为 了 弄 明白 系统 中 正在 
进行 什么 样 的 工作 ， 有 必要 激活 track_io_timing。 如 果 它 被 打开 ，PostgreSQL 将 收集 有 关 
磁盘 等 待 的 信息 并 且 展示 给 用 户 。 

客户 常常 会 问 的 一 个 主要 问题 是 : 如果 我 们 增加 更 多 磁盘 ， 系 统 是 不 是 能 够 更 快 一 
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些 ? 我 们 当然 可 以 猜想 一 下 会 发 生 什么 ， 但 是 通常 来 说 实际 的 测量 才 是 更 好 且 更 有 用 的 
策略 。 启 用 track io timing 将 帮助 用 户 汇集 数据 以 真正 地 找 出 结论 。 
PostgreSQL 以 多 种 方式 向 用 户 显露 磁盘 等 待 的 信息 。 一 种 方法 是 查看 pg_stat database: 


test=# d pg_ stat database 
View "pg catalog.pg stat database" 








Column Type | Modifiers 
EE A se RS 
datid oid 1 
datname name 1 
conflicts bigint 1 
temp files bigint 1 
temp_bytes bigint | 
blk read time double precision 1 
blk write time | double precision 1 


其 中 有 两 个 域 与 上 述 目 的 有 关 : blk read time 和 blk write time。 它 们 将 告诉 我 们 
PostgreSQL 花 在 等 待 OS 响应 上 的 时 间 。 注 意 这 里 实际 上 没有 测量 磁盘 等 待 ， 而 是 测量 操 
作 系 统 返回 数据 所 需 的 时 间 。 如 果 操 作 系 统 产生 了 缓冲 命中 ， 这 种 时 间 将 会 相当 短 。 如 
果 OS 真 地 不 得 不 去 做 随机 IO， 我 们 将 看 到 取得 单个 块 甚至 就 需要 若干 毫秒 。 

在 很 多 情况 下 ， 当 temp_files 以 及 temp_bytes 显示 较 高 的 数字 时 ，blk read time 和 
blk_ write _time 值 就 会 较 高 。 还 有 很 多 情况 下 ，blk_read_time 和 blk_write_time 的 值 很 高 意 
味 着 不 好 的 work_mem 或 maintenance work mem 设置 。 牢 记 这 一 点 : 如 果 PostgreSQL 
无 法 在 内 存 中 执行 操作 ， 它 就 不 得 不 溢出 到 磁盘 ，temp_files 是 检测 这 种 情况 的 方法 。 只 
要 temp_files 中 出 现 值 ， 就 有 可 能 发 生 令 人 不 快 的 磁盘 等 待 。 

虽然 在 每 个 数据 库 级 别 上 的 全 局 视图 很 有 意义 ， 但 从 这 里 无 法 得 到 实际 问题 来 源 的 
深层 信息 。 常 见 的 情况 是 只 有 少数 的 查询 需要 为 不 好 的 性 能 负责 ， 找 到 这 些 查 询 的 方法 
是 使 用 pg_stat_statements: 

test=# d pg stat statements 


View "public.pg stat statements" 
Column 1 Type | Modifiers 


query | text | 
calls | bigint 1 


第 12 章 “在 PostgreSQL 中 排查 错误 "303。 


total time | double precision | 
temp blks read bigint 

temp blks written 
blk read time 
blk write time 


bigint 1 
double precision | 


double precision | 


用 户 将 可 以 以 每 个 查询 为 基础 ， 查 看 是 否 有 磁盘 等 待 。 其 中 重要 的 部 分 是 结合 
total time 查看 blk_ 时间， 它们 之 间 的 比例 才 是 最 有 价值 的 信息 。 通 常 ， 如 果 一 个 查询 有 
30% 的 时 间 用 于 磁盘 等 待 ， 那 么 它 就 可 以 被 视 为 严重 的 1O 密集 型 查询 。 

检查 完 PostgreSQL 的 系统 表 ， 接 下 来 可 以 检查 Linux 上 vmstat 命令 的 结果 。 此 外 ， 
也 可 以 使 用 iostat 命 令 : 

[hs@zenbook ~]$ vmstat 2 

Piocs ----------—- meImoOLY 一 一 一 一 一 一 一 -一 -Swap- -io- -System- ------ cpu----- 

EB swpd free buff cache si so bi bo in cs us sy id wa st 

0 0 367088 199488 96 23203656U 0929863 96 106 156°、166978 0 0 


0 0 367088 198140 96 2320504 .00 0 dd0 5957262473IR 1 96 0 .0 
00 367088 191448 96 2320964 OO ON I 0 2950080 2900090 


在 做 数据 库 工作 时 ， 用 户 应 该 关注 3 个 域 : bi、bo 和 wa。bi 域 告诉 我 们 块 读 取 的 次 
数 ，1000 等 效 于 “MB/s”。bo 域 有 关 写 出 的 块 ， 它 告诉 我 们 被 写 出 到 磁盘 的 数据 量 。 在 
某 种 程度 上 ，bi 和 bo 是 原始 的 吞吐 量 。 笔 者 认为 单 靠 这 两 个 数字 不 能 说 明 性 能 受到 了 伤 
害 ， 真 正 的 问题 是 较 高 的 wa 值 。 较 低 的 bi 和 bo 值 结合 较 高 的 wa 值 将 告诉 我 们 有 可 能 
出 现 了 磁盘 瓶颈 ， 而 这 种 瓶颈 很 可 能 与 系统 中 发 生 的 大 量 随机 VO 有 关 。wa 值 越 高 ， 查 
询 就 越 慢 ， 因 为 用 户 需 要 等 待 磁盘 响应 。 


好 的 原始 吞吐 是 好 事 ， 但 它 也 可 能 表示 有 问题 。 如 果 在 一 个 OLTP 系统 上 
0 需要 高 吞吐 ， 原 始 吞 吐 将 会 告诉 用 户 没有 足够 的 RAM 来 缓冲 数据 或 者 
PostgreSQL 由 于 缺少 索引 而 不 得 不 读 取 太 多 数据 。 记 住 这 些 检测 数据 之 间 都 是 

相互 联系 的 ， 不 应 该 孤立 地 看 待 数据 。 








12.7 了 解 值得 注意 的 错误 场景 


在 给 出 了 追踪 最 常见 问题 的 基本 指导 方针 后 ， 本 节 将 讨论 PostgreSQL 世界 中 发 生 的 
一 些 最 常见 的 错误 场景 。 
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12.7.1 面 对 clog 损坏 


PostgreSQL 有 一 种 被 称 作 提交 日 志 的 东西 ， 它 也 被 叫 作 clog。 它 跟踪 系统 中 每 一 个 
事务 的 状态 并 且 帮 助 PostgreSQL 判断 一 行 是 否 可 见 。 通 常 ， 一 个 事务 可 以 处 于 4 种 状态 : 

#define TRANSRCTION STATUS IN PROGRESS 0x00 

#define TRANSACTION STATUS COMMITTED Ox01 

#define TRANSACTION STATUS ABORTED 0x02 

#define TRANSACTION STATUS SUB COMMITTED 0x03 


clog 在 PostgreSQL 数据 库 实例 中 有 一 个 单独 的 目录 。 

在 过 去 ， 人 们 已 经 报告 了 一 种 被 称 为 clog 损坏 的 问题 ， 这 种 问题 可 能 由 有 缺点 的 磁 
盘 或 者 PostgreSQL 中 的 缺陷 (已 经 在 过 去 的 这 些 年 中 被 修复 ) 造成 。 碰 到 损坏 的 提交 日 
志 是 非常 让 人 不 快 的 事情 ， 因 为 所 有 的 数据 都 还 在 ， 但 是 PostgreSQL 却 再 也 无 法 知道 哪 
些 可 用 哪些 不 可 用 。 这 一 领域 的 损坏 无 异 于 一 场 彻头彻尾 的 灾难 。 

管理 员 如 何 能 够 得 知 提交 日 志 损坏 呢 ? 管理 员 通 常 将 会 看 到 ; 


ERROR: could not access status of transaction 118831 


如 果 PostgreSQL 无 法 访问 事务 的 状态 ， 当 然 就 有 麻烦 。 主 要 的 问题 是 如 何 修复 这 类 问 
题 ? 直截了当 地 说 ， 没 有 办 法 真正 地 修复 该 问题 一 一 用 户 只 能 尝试 尽 可 能 多 地 抢救 数据 。 

如 前 所 述 ， 提 交 日 志 为 每 个 事务 保持 两 个 位 。 这 意味 着 在 每 个 字 节 中 存 有 4 个 事 
务 ， 因 此 每 个 块 中 有 32768 个 事务 。 一 旦 找 出 哪个 块 损坏 ， 用 户 就 可 以 伪造 事务 日 志 : 


dd if=/dev/zero of=<data directory location>/pg clog/0001 
bs=256K count=1 


用 户 可 以 使 用 dd 来 伪造 事务 日 志 并 且 将 提交 状态 设置 为 想 要 的 值 。 其 核心 问题 是 
应 该 使 用 哪 种 事务 状态 ? 答案 是 任何 状态 实际 上 都 是 错误 的 ， 因 为 我 们 实在 不 知道 那些 
事务 是 怎样 结束 的 。 不 过 为 了 让 损失 的 数据 更 少 ， 通 常 把 那些 事务 设置 为 已 提交 会 比较 
好 。 在 决定 怎么 做 破坏 最 小 时 ， 实 际 上 取决 于 用 户 的 工作 负载 和 数据 。 

当 用 户 不 得 不 这 样 做 时 ， 应 该 尽 可 能 少 地 伪造 clog。 注 意 ， 我 们 实际 上 是 在 伪造 提 
交 状 态 ， 这 对 数据 库 引擎 来 说 并 不 是 什么 好 事 。 

一 旦 完成 了 伪造 clog， 用 户 应 该 尝试 尽快 创建 一 个 备份 并 且 从 零 开 始 重建 数据 库 实 
例 。 用 户 正在 使 用 的 系统 不 再 可 信 ， 因 此 用 户 应 该 尝试 尽快 提取 出 数据 。 请 记 住 : 用 户 
将 要 抽取 的 数据 可 能 会 是 矛盾 的 和 错误 的 ， 因 此 要 确保 对 能 从 数据 库 服务 器 中 抢救 出 来 
的 数据 做 一 些 质量 检查 。 
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12.7.2 ”理解 检查 点 消息 


检查 点 对 于 数据 完整 性 以 及 性 能 都 必 不 可 少 。 检 查 点 之 间 离 得 越 远 ， 通 常 性 能 就 越 
好 。 在 PostgreSQL 中 ， 默 认 的 配置 通常 相当 保守 ， 因 此 检查 点 相对 比较 快 。 如 果 做 检查 
点 的 同时 数据 库 核 心中 有 大 量 数据 被 改变 ，PostgreSQL 可 能 会 告诉 我 们 它 认为 检查 点 过 
频 。 日 志文 件 将 显示 下 列 项 : 

LOG: checkpoints are occurring too frequently (2 seconds apart) 

LOG: checkpoints are occurring too frequently (3 seconds apart) 


在 转 储 /恢复 或 者 其 他 大 型 操作 造成 的 重度 写 过 程 中 ，PostgreSQL 可 能 会 提示 配置 参 
数 设置 得 过 低 。 日 志 中 会 记录 一 条 消息 来 告诉 我 们 这 些 。 

如 果 用 户 看 到 这 类 消息 ， 出 于 性 能 原因 ， 笔 者 强烈 推荐 通过 大 幅 增加 max_wal size 
参数 〈 较 老 的 版 本 中 该 设置 被 称 作 checkpoint segments) 来 增加 检查 点 的 距离 。 在 最 近 版 
本 的 PostgreSQL 中 ， 默 认 的 配置 已 经 比 以 前 常用 的 配置 好 了 很 多 。 不 过 ， 过 于 频繁 地 写 
数据 仍然 很 容易 发 生 。 

当 用 户 看 到 一 条 有 关 检 查 点 的 消息 时 ， 有 一 点 必须 牢记 : 检查 点 过 频 根本 就 不 危 
险 一 一 它 只 是 会 导致 不 太 好 的 性 能 。 写 入 确实 会 慢 很 多 但 是 数据 没有 危险 。 把 两 个 检查 
点 间 的 距离 增加 到 足够 大 将 会 避免 这 种 错误 并 且 同 时 加 快 数据 库 实例 的 速度 。 


12.7.3 ”管理 损坏 的 数据 页 面 


PostgreSQL 是 一 种 非常 稳定 的 数据 库 系统 ， 它 会 尽 可 能 地 保护 数据 并 且 已 经 在 过 去 
的 岁月 里 证 明了 其 价值 。 但 是 ，PostgreSQL 依赖 于 硬件 和 一 种 正确 工作 的 文件 系统 。 如 
果 存 储 损坏 ，PostgreSQL 也 将 损坏 一 一 除了 增加 复制 系统 确保 万 无 一 失 之 外 确实 无 法 做 
到 更 多 。 

有 时 候 ， 文 件 系统 或 者 磁盘 可 能 会 失效 。 但 是 在 很 多 情况 下 ， 整 个 系统 将 不 会 变 得 
越 来 越 糟 ， 只 是 有 若干 块 由 于 某 种 原因 损坏 。 近 来 ， 我 们 已 经 在 虚拟 环境 中 见 过 这 类 情 
况 的 发 生 。 一 些 虚拟 机 不 会 默认 刷 入 磁盘 ， 这 就 意味 着 PostgreSQL 不 能 信赖 被 写 入 到 磁 
盘 的 东西 。 这 类 行为 可 能 导致 很 难 预 测 的 随机 问题 。 

如 果 一 个 块 无 法 再 被 读 取 ， 用 户 可 能 会 看 到 下 面 这 样 的 一 条 错误 消息 : 


vcould not read block Su in file "Ss": Sm 


将 要 运行 的 查询 将 会 报错 并 且 停 止 工作 。 
幸运 的 是 ，PostgreSQL 有 方法 能 处 理 这 类 事情 : 
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test=# SET zero damaged pages TO on; 
SET 

test=# SHOW zero damaged pages; 
zero_damaged pages 


(1 row) 


zero_damaged_pages 是 一 个 配置 变量 ， 它 允许 用 户 处 理 损坏 的 页 面 。PostgreSQL 将 
拿 到 这 样 的 块 并 且 将 它 简单 地 用 零 填充 ， 而 不 是 抛 出 错误 。 

注意 ， 这 无 疑 将 导致 数据 丢失 。 但 不 管 怎样 ， 数 据 之 前 就 已 经 损坏 或 者 丢失 ， 因 此 
这 只 是 一 种 处 理 存 储 系统 中 故障 导致 的 数据 损坏 的 方式 而 已 。 

笔者 会 建议 大 家 小 心地 处 理 zero_damaged_pages 变量 
在 做 什么 。 


12.7.4 ”粗心 的 连接 管理 


在 PostgreSQL 中 ， 每 一 个 数据 库 连 接 都 是 一 个 单独 的 进程 。 所 有 那些 进程 使 用 共享 
内 存 〈 在 技术 上 来 看 ， 大 部 分 情况 下 是 映射 内 存 ， 但 对 这 个 例子 来 说 没什么 区 别 ) 同 
步 。 这 块 共享 内 存 包含 IO 缓冲 、 活 动 的 数据 库 连 接 列表 、 锁 以 及 让 系统 功能 正确 的 更 多 
关键 数据 。 

当 一 个 连接 被 关闭 时 ， 它 将 从 共享 内 存 中 移 除 所 有 相关 项 并 且 让 系统 处 于 一 种 健全 
的 状态 。 但 是 ， 当 数据 库 连 接 由 于 某 种 原因 崩溃 时 会 发 生 什 么 ? 

postmaster 〈 主 进程 ) 将 检测 到 一 个 子 进程 不 见 了 。 然 后 ， 所 有 其 他 连接 都 将 被 终止 
并 且 一 个 前 滚 进程 将 被 初始 化 。 为 什么 要 这 样 ? 当 一 个 进程 崩溃 时 ， 它 可 能 正好 在 编辑 
享 内 存 区 域 。 换 名 话说， 一 个 崩溃 的 进程 可 能 会 在 共享 内 存 中 留 下 损坏 的 状态 。 因 
此 ，postmaster 会 行动 起 来 并 且 在 这 种 损坏 在 系统 中 传播 之 前 把 所 有 人 都 从 系统 中 踢 出 
去 。 所 有 的 内 存 会 被 清理 并 且 所 有 人 都 必须 重新 连接 。 

从 最 终 用 户 的 角度 来 看 ， 这 种 现象 感觉 就 是 PostgreSQL 整个 崩溃 并 且 重 启 ， 但 事实 
非 如 此 。 由 于 进程 无 法 在 自己 崩溃 〈 段 错误 ) 或 收 到 某 些 其 他 信号 时 做 出 反应 ， 因 此 
清除 所 有 东西 对 于 保护 数据 来 说 绝对 是 至 关 重 要 的 。 如 果 用 户 在 数据 库 连接 上 使 用 kill -9 
命令 也 会 发 生 同 样 的 事情 。 该 连接 无 法 捕 提 到 该 信号 〈-9 不 能 根据 定义 捕捉 〉， 因 此 
postmaster 必须 做 出 反应 。 


12.7.5 与 表 膨 胀 斗争 
在 使 用 

















在 调用 它 时 要 意识 到 自己 




























































































PostgreSQL 时 ， 表 膨胀 是 最 





要 的 问题 之 一 。 如 果 遇 到 不 好 的 性 能 ， 找 出 是 
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否 有 对 象 使 用 了 比 预 期 更 多 的 空间 总 是 一 个 好 主意 。 
怎样 才能 找 出 哪里 发 生 了 表 膨 胀 呢 ? 可 以 考虑 检查 pg_stat_user_tables 参数 : 


test=# d pg_stat_ user tables 





View "pg catalog.pg stat user tables" 


Column | Type | Modifiers 
二 Na 
relid I asia 
schemaname | name 
relname | name 


n live tup 


[en 
所 
[ee] 
PF- 
| 
t+ 


n_dead tup 


n_live_tup 和 n_dead_tup 域 将 会 让 我 们 对 表 膨 胀 的 情况 形成 印象 。 用 户 也 可 以 使 用 第 
11 章 介绍 的 pgstattuple。 

如 果 出 现 了 严重 的 表 膨 胀 ， 我 们 能 做 什么 ”首选 项 是 运行 VACUUM FULL 子 句 。 但 
问题 是 VACUUM FULL 子 句 需要 一 个 表 锁 。 在 一 个 大 型 的 表 上 ， 这 种 加 锁 的 操作 可 能 会 
是 一 个 大 问题 ， 因 为 在 表 被 重 写 期 间 用 户 无 法 对 该 表 做 写 操作 。 

如 果 使 用 的 是 PostgreSQL 9.6 以 上 的 版 本 ， 用 户 可 以 使 用 一 种 名 为 pg_squeeze 的 工 
具 ， 它 会 在 后 台 组 织 表 而 无 须 阻塞 其 他 操作 : http://www.cybertec.at/introducing-pg_squeeze-a- 
postgresql-extension-to-auto-rebuild-bloated-tables/。 


[en 
PF- 
be 
[= 
总 
t+ 


9 如 果 要 重新 组 织 一 个 非常 大 的 表 ， 这 种 工具 特别 有 用 。 


12.8 总 结 


在 本 章 中 ， 读 者 学 到 了 如 何 系统 地 着 手 处 理 一 个 数据 库 系 统 并 且 检 测 使 用 PostgreSQL 
会 遇 到 的 最 常见 的 问题 。 读 者 学 到 了 一 些 重要 的 系统 表 以 及 其 他 一 些 重要 的 因素 ， 它 们 
决定 着 我 们 是 否 能 够 成 功 地 完成 故障 排除 工作 。 
在 本 书 的 最 后 一 章 中 ， 我 们 将 聚焦 于 向 PostgreSQL 迁移 这 一 话题 。 如 果 读 者 正在 使 
Oracle 或 者 某 种 其 他 的 数据 库 系 统 ， 读 者 可 能 想 要 试 试 PostgreSQL。 第 13 章 将 告诉 大 
家 如 何 做 这 件 事 。 
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第 13 章 迁移 到 PostgreSQL 


在 第 12 章 ， 笔 者 展示 了 如 何 处 理 与 PostgreSQL 故障 排除 相关 的 最 常见 的 问题 。 重 点 
是 用 一 种 系统 的 方法 来 追踪 问题 ， 这 也 是 笔者 想 要 尝试 提供 的 东西 。 

本 书 的 最 后 一 章 与 转移 到 PostgreSQL 有 关 。 很 多 读者 可 能 仍然 忍受 着 商业 数据 库 许 
可 证 花 销 的 煎熬 ， 笔 者 想 要 告诉 所 有 这 些 用 户 一 条 出 路 ， 并 且 展 示 如 何 把 数据 从 某 种 专 
有 系统 中 转移 到 PostgreSQL。 转 移 到 PostgreSQL 不 仅仅 在 财务 方面 有 意义 ， 还 可 以 为 用 
户 带 来 更 多 先进 的 特性 以 及 更 多 的 灵活 性 。PostgreSQL 有 非常 多 的 特性 可 以 提供 给 用 
户 ， 并 且 在 我 们 谈论 它 时 不 断 有 新 特性 被 加 入 。 

本 章 将 涵盖 以 下 内 容 : 

@ 把 SQL 语句 迁移 到 PostgreSQL。 

@ ”从 Oracle 转移 到 PostgreSQL。 

@ ”从 MySQL 转移 到 PostgreSQL 。 

在 本 章 结束 时 ， 读 者 应 该 能 够 从 某 种 其 他 系统 把 一 个 基本 的 数据 库 转移 到 PostgreSQL。 


13.1 迁移 SQL 语句 到 PostgreSQL 





在 从 一 个 数据 库 转 移 到 PostgreSQL 时 ， 有 必要 先 看 看 哪 种 数据 库 引 擎 提供 哪 种 功 
能 。 转 移 数据 和 结构 本 身 通常 相当 容易 。 但 是 ， 重 写 SQL 可 能 就 不 是 这 样 了 。 因 此 ， 笔 
者 决定 用 一 个 小 节 来 介绍 SQL 的 多 种 先进 特性 以 及 它们 在 当今 数据 库 引擎 中 的 可 用 性 。 

在 本 节 中 将 履 盖 最 重要 的 内 容 。 为 了 成 功 地 转移 数据 库 ， 有 必要 理解 哪 种 数据 库 支 持 
哪些 特性 。 在 接 下 来 的 小 节 中 ， 笔 者 选择 了 最 常见 的 数据 库 引擎 并 且 给 出 了 它们 的 对 比 。 


13.1.1 使 用 侧 连接 


在 SQL 中 ， 侧 连接 (lateral join) 基本 上 可 以 被 视 为 某 种 循环 。 它 允许 我 们 参数 化 一 
个 连接 并 且 多 次 执行 LATERAL 子 句 中 的 所 有 东西 。 这 里 是 一 个 简单 的 例子 : 


test=# SELECT * 
FROM generate series (1，4) AS x, 
LATERAL (SELECT array agg(y) 
FROM generate series(1, x) ASy 
| 
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| array agg 
NE 
1 

1 

1 

1 


{1,2,3,4} 
rows) 


这 个 例子 将 为 每 个 x 调用 LATERAL 子 句 。 对 于 最 终 用 户 来 说 ， 这 说 白 了 就 是 某 种 


循环 。 
@ 


支持 lateral 


在 本 章 中 ， 读 者 将 学 到 有 关 多 种 数据 库 的 很 多 知识 并 且 弄 清 哪 种 引擎 支持 哪些 特 
性 。 一 种 重要 的 SQL 特性 就 是 侧 连接 。 下 面 的 列表 展示 了 哪些 引擎 支持 侧 连接 以 及 哪些 


不 支持 。 


MariaDB: 不 支持 。 

MySQL: 不 支持 。 

PostgreSQL: 从 PostgreSQL 9.3 开始 支持 。 

SQLite: 不 支持 。 

DB2 LUW: 从 版 本 9.1 (2005) 开始 支持 。 

Oracle: 从 12c 开始 支持 。 

MS SQL Server: 从 2005 开始 支持 ， 但 使 用 了 不 同 的 语法 。 


13.1.2 ”使 用 分 组 集 

如 果 用 户 想 要 同时 运行 多 于 一 种 聚集 ， 分 组 集 就 非常 有 用 。 使 用 分 组 集 可 以 加 速 聚 
集 ， 因 为 它 不 需要 一 次 又 一 次 地 处 理 数 据 。 

例如 : 


tes 


t=# SELECT x $% 2, array agg (x) 
FROM generate series (1，4) AS x 
GROUP BY ROLLUP (1); 


?column? | array agg 


EE a 
OU L2R 人 9 
1 居 全 直 
| {2,4,1,3} 
rows) 
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PostgreSQL 提供 的 不 止 ROLLUP 子 句 ， 还 支持 CUBE 和 GROUPING SETS 子 句 。 
@ 支持 分 组 集 
分 组 集 本 质 上 是 在 单个 查询 中 生成 多 于 一 种 聚集 。 下 面 的 列表 展示 了 哪些 引擎 支持 
分 组 集 以 及 哪些 不 支持 。 
@ MariaDB: 从 5.1 开 始 只 支持 ROLLUP 子 句 〈 不 完全 支持 ) 。 
MySQL: 从 5.0 开 始 只 支持 ROLLUP 子 句 〈 不 完全 支持 ) 。 
PostgreSQL: 从 PostgreSQL 9.5 开始 支持 。 
SQLite: 不 支持 。 
DB2 LUW: 至 少 从 1999 年 开始 支持 。 
Oracle: 从 9iR1 (大 约 2000 年 ) 开始 支持 。 
MS SQL Server: 从 2008 年 开始 支持 。 


13.1.3 ”使 用 WITH 子 名 一 一 公共 表 表 达 式 


公共 表 表 达 式 是 一 种 在 SQL 语句 内 一 次 性 执行 东西 的 好 方法 。PostgreSQL 将 执行 所 
有 的 WITH 子 句 并 且 允 许 在 整个 查询 中 到 处 使 用 其 结果 。 
下 面 是 一 个 简化 的 例子 : 


test=# WITH x AS (SELECT avg (id) 
FROM generate series(1, 10) AS id) 
SELECT *, y - (SELECT avg FROM x) RS diff 
FROM generate series(1, 10) RS Y 
WHERE Y > (SELECT avg FROM x); 
Y 1 diff 








.5000000000000000 
.5000000000000000 
.5000000000000000 
.5000000000000000 
1 4.5000000000000000 


在 这 个 例子 中 ，WITH 子 句 公共 表 表 达 式 (CTE) 计算 generate_series 函数 生成 的 时 
间 序 列 的 均值 。 其 结果 x 就 像 一 个 表 一 样 可 以 在 查询 的 各 处 使 用 。 在 笔者 的 例子 中 x 被 
使 用 了 两 次 。 

@ 支持 WITH 子 句 

下 面 展 示 了 哪些 引擎 支持 WITH 子 句 以 及 哪些 不 支持 。 
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@ MariaDB: 不 支持 。 

@ MySQL: 不 支持 。 

@ PostgreSQL: 从 PostgreSQL 8.4 开始 支持 。 

@ SQLite: 从 3.8.3 开始 支持 。 

@ DB2LUW: 从 8 (2000 年 ) 开始 支持 。 

@ Oracle: 从 9iR2 开始 支持 。 

@ MS SQL Server: 从 2005 年 开始 支持 。 

注意 在 PostgreSQL 中 ，CTE 甚至 可 以 支持 写 操作 (INSERT、UPDATE 以 及 DELETE 
了 条) 5 


13.1.4 使 用 WITH RECURSIVE 子 句 


WITH 子 句 会 以 两 种 形式 出 现 : 

@ 13.1.3 节 中 的 标准 CTE (使 用 WITH 子 句 )。 

@ 在 SQL 中 运行 递归 的 方法 。 

CTE 的 简单 形式 已 经 被 13.1.3 节 所 涵盖 ， 在 本 节 中 将 涵盖 递归 版 本 。 
@ 支持 WITH RECURSIVE 子 句 

下 面 展示 了 哪些 引擎 支持 WITH RECURSIVE 子 句 以 及 哪些 不 支持 。 
MariaDB: 不 支持 。 

MySQL: 不 支持 。 

PostgreSQL: 从 PostgreSQL 8.4 开始 支持 。 

SQLite: 从 3.8.3 开始 支持 。 

DB2 LUW: 从 7 (2000 年) 开始 支持 。 

Oracle: 从 11gR2 开始 支持 (在 Oracle 中 ， 通 常 更 多 使 用 CONNECT BY 子 句 而 
不 是 WITH RECURSIVE 子 句 ) 。 

@ MS SQL Server: 从 2005 开始 支持 。 


13.1.5 ”使 用 FILTER 子 名 


在 查看 SQL 标准 本 身 时 ， 读 者 将 会 注意 到 FILTER 子 句 已 经 在 SQL 中 存在 了 很 久 
(2003 年 就 有 了 ) 。 但 是 ， 并 没有 很 多 系统 真正 支持 这 一 非常 有 用 的 语法 元 素 。 
例如 : 


test=# SELECT count(*), 
Count (*) FILTER (WHERE id < 5), 
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Count (*) FILTER (WHERE id > 2) 
FROM generate series(1, 10) AS id; 


count | count | count 


(1 row) 


如 果 一 个 条 件 由 于 某 个 其 他 聚集 需要 该 数据 而 不 能 被 用 在 普通 的 WHERE 子 句 中 ， 
那么 FILTER 子 句 就 能 发 挥 作用 。 
在 FILTER 子 句 被 引入 之 前 ， 同 样 的 事情 可 以 用 一 种 更 加 麻烦 的 语法 实现 : 
SELECT sum(CASE WHEN .. THEN 1 ELSE 0 END) AS whatever 
FROM some table; 
@ 支持 FILTER 子 句 
下 面 展 示 了 哪些 引擎 支持 FILTER 子 句 以 及 哪些 不 支持 。 
MariaDB: 不 支持 。 
MySQL: 不 支持 。 
PostgreSQL: 从 PostgreSQL 9.4 开始 支持 。 
SQLite: 不 支持 。 
DB2 LUW: 不 支持 。 
Oracle: 不 支持 。 
MS SQL server: 不 支持 。 


13.1.6 ”使 用 窗口 函数 


本 书 中 已 经 深入 地 讨论 过 窗口 和 数据 分 析 。 因 此 ， 我 们 就 直接 跳 到 SQL 兼容 部 分 。 
@ 支持 窗口 和 分 析 

下 面 展示 了 哪些 引擎 支持 窗口 函数 以 及 哪些 不 支持 。 

MariaDB: 不 支持 。 

MySQL: 不 支持 。 

PostgreSQL: 从 PostgreSQL 8.4 开始 支持 。 

SQLite: 不 支持 。 

DB2 LUW: 从 版 本 7 开始 支持 。 

Oracle: 从 版 本 8i 开始 支持 。 

MS SQL server: 从 2005 开始 支持 。 
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省 一 些 其 他 的 数据 库 ， 例 如 Hive、Impala、Spark 和 NuoDB 等 也 支持 数据 分 析 。 


13.1.7 使 用 有 序 集 一 一 WITHIN GROUP 子 句 


有 序 集 对 于 PostgreSQL 是 相当 新 的 特性 。 有 序 集 和 普通 聚集 的 差别 在 于 ， 在 有 序 集 
中 ， 数 据 输送 给 聚集 的 方式 确实 有 区 别 。 假 定 用 户 想 要 在 数据 中 找到 一 种 趋势 一 一 数据 
的 顺序 与 之 相关 。 
下 面 是 一 个 计算 中 位 数值 的 简单 例子 : 
test=# SELECT id % 2, 
percentile disc(0.5) WITHIN GROUP (ORDER BY id) 
FROM generate series(1, 123) AS id 
GROUP BY 1; 
?column? | percentile disc 





(2 rows) 

只 有 在 有 排序 输入 时 中 位 数 才能 被 确定 。 

@ 支持 WITHIN GROUP 子 句 

下 面 展 示 了 哪些 引擎 支持 WITH GROUP 子 句 ?以 及 哪些 不 支持 。 
MariaDB: 不 支持 。 

MySQL: 不 支持 。 

PostgreSQL: 从 PostgreSQL 9.4 开始 支持 。 
SQLite: 不 支持 。 

DB2 LUW: 不 支持 。 

Oracle: 从 版 本 9iR1 开始 支持 。 

MS SQL Server: 必须 重 构 查 询 来 使 用 窗口 函数 。 


13.1.8 使 用 TABLESAMPLE 子 句 


表 采 样 长 久 以 来 都 是 商业 数据 库 提 供 商 的 实力 所 在 。 多 年 前 ， 传 统 的 数据 库 系 统 已 
经 提供 了 采样 。 但 是 ， 这 种 垄断 已 经 被 打破 。 从 PostgreSQL 9.5 开始 ， 我 们 也 拥有 采样 问 





9 原文 是 “窗口 函数 ”， 应 为 笔 误 。 
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题 的 解决 方案 了 。 
例如 : 


test=# CREATE TABLE t test (id int); 
CREATE TABLE 
test=# INSERT INTO t test 
SELECT * FROM generate series(1, 1000000); 
INSERT 0 1000000 


首先 创建 一 个 含有 1 百 万 行 的 表 。 然 后 可 以 执行 测试 : 


test=# SELECT count(*), avg (id) 
FROM t test TABLESAMPLE BERNOULLI (1); 


count avg 

ST 
9802 502453.220873291165 

(1 row) 


test=# SELECT count(*), avg(id) 
FROM 七 test TABLESAMPLE BERNOULLI (1); 


count avg 

与 二 A 
10082 497514.321959928586 
(1 row) 





在 这 个 例子 中 ， 从 数据 中 取得 了 1% 的 样本 。 平 均值 很 接近 于 50 万 "， 因 此 从 统计 的 
角度 来 看 ， 该 结果 很 不 错 。 
@ 支持 TABLESAMPLE 子 名 
下 面 展示 了 哪些 引擎 支持 TABLESAMPLE 子 句 以 及 哪些 不 支持 。 
@ MariaDB: 不 支持 。 
MySQL: 不 支持 。 
PostgreSQL: 从 PostgreSQL 9.5 开始 支持 。 
SQLite: 不 支持 。 
DB2 LUW: 从 版 本 8.2 开始 支持 。 
Oracle: 从 版 本 8 开始 支持 。 
MS SQL Server: 从 2005 开始 支持 。 
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13.1.9 ”使 用 limit/offset 


在 SQL 中 ， 限 制 结果 多 少 有 点 悲剧 色彩 。 长 话 短 说 ， 每 个 数据 库 的 行事 方式 多 少 有 
些 不 同 。 尽 管 在 限制 结果 上 确实 有 SQL 标准 ， 但 并 不 是 所 有 人 都 完全 以 那 种 方式 支持 这 
一 特性 。 限 制 数据 的 正确 方式 实际 上 应 该 是 使 用 下 面 的 语法 : 

test=# SELECT * FROM t test FETCH FIRST 3 ROWS ONLY; 

id 





间 
3 


(3 rows) 


如 果 读 者 之 前 从 未 见 过 这 种 语法 ， 不 用 担心 ， 你 并 不 孤独 。 
@ 支持 FETCHFIRST 子 句 
下 面 展示 了 哪些 引擎 支持 FETCH FIRST 子 句 以 及 哪些 不 支持 。 
MariaDB: 从 5.1 开始 支持 (通常 使 用 limit/offset〉。 
MySQL: 从 3.19.3 开始 支持 (通常 使 用 limit/offset〉。 
PostgreSQL: 从 PostgreSQL 8.4 开始 支持 (通常 使 用 limit/offset) 。 
SQLite: 从 版 本 2.1.0 开始 支持 。 
DB2 LUW: 从 版 本 7 开始 支持 。 
Oracle: 从 版 本 12c 开始 支持 〈 使 用 带 有 row_num 函数 "的 子 选 择 ) 。 
MS SQL Server: 从 2012 开始 支持 (使 用 传统 的 top-N) 。 
如 你 所 见 ， 限 制 结果 集 非常 难以 对 付 ， 而 且 当 用 户 从 一 种 商业 数据 库 移植 到 PostgreSQL 
时 ， 用 户 将 很 可 能 会 面 对 某 些 专用 语法 。 


13.1.10 使 用 OFFSET 


OFFSET 子 句 是 和 FETCH FIRST 子 句 类 似 的 戏法 。 它 易于 使 用 ， 但 是 在 早期 并 未 被 
广泛 采纳 。 它 并 不 像 FETCH FIRST 子 句 的 情况 那么 糟糕 ， 但 是 它 仍然 可 能 导致 问题 。 

@ 支持 OFFSET 子 句 

下 面 展 示 了 哪些 引擎 支持 OFFSET 子 句 以 及 哪些 不 支持 。 
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MariaDB: 从 5.1 开始 支持 。 
MySQL: 从 4.0.6 开始 支持 。 
PostgreSQL: 从 PostgreSQL 6.5 开始 支持 。 
SQLite: 从 版 本 2.1.0 开始 支持 。 
DB2 LUW: 从 版 本 11.1 开始 支持 。 
Oracle: 从 版 本 12c 开始 支持 。 
MS SQL Server: 从 2012 开始 支持 。 
如 你 所 见 ， 限 制 结果 集 非 常 难以 对 付 ， 而 且 当 用 户 从 一 种 商业 数据 库 移植 到 
PostgreSQL 时 ， 用 户 将 很 可 能 会 面 对 某 些 专用 语法 。 


13.1.11 使 用 临时 表 


某 些 数据 库 引 擎 提供 临时 表 来 处 理 版 本 管理 。 不 幸 的 是 ， 在 PostgreSQL 中 并 没有 自 
带 这 种 特性 。 因 此 ， 如 果 从 DB2 或 者 Oracle 进行 转移 ， 用 户 需要 做 一 些 工 作 来 把 想 要 的 
功能 移植 到 PostgreSQL。 说 白 了 ， 在 PostgreSQL 端 改 一 点 代码 并 不 难 。 但 是 ， 那 确实 需 
要 一 些 人 工 介 入 一 一 这 已 经 不 再 是 直接 复制 粘贴 就 能 解决 的 。 

@ 支持 临时 表 

下 面 展 示 了 哪些 引擎 支持 临时 表 以 及 哪些 不 支持 。 

MariaDB: 不 支持 。 

MySQL: 不 支持 。 

PostgreSQL: 不 支持 。 

SQLite: 不 支持 。 

DB2 LUW: 从 版 本 10.1 开始 支持 。 
Oracle: 从 版 本 12cR1 开始 支持 。 
MS SQL server: 从 2016 开始 支持 。 


13.1.12 ”匹配 时 间 序 列 中 的 模式 


笔者 注意 到 最 近 的 SQL 标准 〈SQL 2016) 提供 了 一 种 特性 ， 该 特性 为 在 时 间 序 列 中 
查找 匹配 而 设计 。 到 目前 为 止 只 有 Oracle 在 最 新 的 产品 版 本 中 实现 了 这 一 功能 。 
在 这 一 点 上 ， 还 没有 其 他 数据 库 供应 商 跟 进 并 且 增 加 类 似 的 功能 。 如 果 用 户 想 在 
PostgreSQL 中 模拟 这 种 最 新 的 技术 ， 就 必须 与 窗口 函数 和 子 查询 打交道 。 在 Oracle 中 匹 
配 时 间 序 列 模式 的 功能 相当 强大 ， 在 PostgreSQL 中 没有 一 种 查询 能 实现 同样 的 功能 。 








第 13 章 迁移 到 PostgreSQL “317。 


13.2 ”从 Oracle 转移 到 PostgreSQL 


到 目前 为 止 ， 读 者 已 经 见 到 了 如 何在 PostgreSQL 中 移植 或 使 用 最 重要 的 特性 。 在 这 
一 介绍 之 后 ， 现 在 可 以 专门 介绍 有 关 迁 移 Oracle 数据 库 的 内 容 。 

如 今 ， 由 于 Oracle 新 的 许可 证 和 商业 策略 ， 从 Oracle 迁移 到 PostgreSQL 已 经 变 得 非 
常 流行 。 在 全 球 ， 人 们 都 在 从 Oracle 离开 并 且 采 用 PostgreSQL。 为 了 帮助 那些 不 再 使 用 
Oracle 的 人 们 ， 笔 者 在 这 里 包括 了 一 个 特别 的 小 节 。 很 多 人 已 经 开始 转移 到 PostgreSQL 
以 大 量 降 低 耗 费 在 许可 证 上 的 开销 。 


13.2.1 使 用 oracle_fdw 扩展 转移 数据 


笔者 最 喜欢 的 一 种 从 Oracle 转移 到 PostgreSQL 的 方法 是 Laurenz Albe 的 oracle_fdw 
扩展 (https://github.com/laurenz/oracle fdw) 。 它 是 一 种 外 部 数据 包装 器 (FDW) ， 它 允 
许 用 户 把 一 个 Oracle 中 的 表 表 示 为 PostgreSQL 中 的 表 。oracle_fdw 扩展 是 最 复杂 的 FDW 
之 一 ， 它 非常 稳固 可 靠 、 有 完善 的 文档 、 免 费 而 且 开 源 。 

安装 oracle fdw 扩展 要 求 用 户 安装 Oracle 的 客户 端 库 。 幸 运 的 是 ， 已 经 有 一 些 可 以 直 
接 使 用 的 RPM 包 (http://www.oracle.com/technetwork/topics/linuxx86-64soft-092277.html》。 
oracle_ fdw 扩展 需要 OCI 驱动 器 以 便 与 Oracle 进行 对 话 。 除 了 使 用 现成 Oracle 客户 端 驱 
动 之 外 ， 还 有 一 个 社区 提供 的 用 于 oracle_fdw 扩展 本 身 的 RPM 包 。 如 果 用 户 用 的 不 是 一 
个 基于 RPM 的 系统 ， 用 户 可 能 必须 自行 编译 ， 这 显然 是 可 行 的 但 工作 量 有 点 大 。 

一 旦 软件 被 安装 好 ， 就 可 以 很 容易 地 启用 它 : 


test=# CREATE EXTENSION oracle fdw; 


CREATE EXTENSION 子 句 把 该 扩展 装载 到 用 户 想 要 的 数据 库 中 。 下 一 步 ， 可 以 创 
建 一 台 服 务 器 并 且 把 用 户 映射 到 它们 在 Oracle 端 对 应 的 用 户 : 
test=# CREATE SERVER oraserver FOREIGN DATA WRAPPER oracle fdw 
OPTIONS (dbserver '//dbserver.example.com/ORADB'); 
test=# CREATE USER MAPPING FOR postgres SERVER oradb 
OPTIONS (user 'orauser', password ‘orapass'); 


然后 就 可 以 取得 一 些 数据 。 笔 者 最 喜欢 的 方法 是 使 用 IMPORT FOREIGN SCHEMA 
子 句 来 导入 数据 定义 。IMPORT FOREIGN SCHEMA 子 句 将 会 为 远程 方案 中 的 每 一 个 表 
都 创建 一 个 外 部 表 ，Oracle 端的 数据 就 可 以 通过 外 部 表 披 露 给 PostgreSQL 的 用 户 ， 这 些 
数据 之 后 可 以 被 很 容易 地 读 取 。 
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利用 导入 方案 最 简单 的 方法 是 在 PostgreSQL 上 创建 单独 的 方案 ， 它 们 只 保存 数据 库 
模式 ， 然 后 可 以 使 用 FDW 很 容易 地 把 数据 吸取 到 PostgreSQL 中 。 本 书 13.3 节 中 有 关 从 
MySQL 迁移 的 内 容 展 示 了 如 何 用 MySQL/MariaDB 实现 的 例子 。 记 住 IMPORT FOREIGN 


SCHEMA 子 句 是 SQL/MED 标准 的 一 部 分 ， 因 








乎 适用 于 每 一 种 支持 IMPORT FOREIGN SCHEMA 子 句 的 FDW。 


虽然 oracle fdw 扩展 为 用 户 做 了 大 部 分 的 了 








比 其 过 程 与 MySQL/MariaDB 相同 。 这 几 


[ 作 ， 但 还 是 有 必要 看 看 数据 类 型 是 如 何 


被 映射 的 。Oracle 和 PostgreSQL 并 未 提供 完全 相同 的 数据 类 型 ， 因 此 需要 oracle_fdw 扩 











Oracle 类 型 ， 而 右边 表示 可 能 的 PostgreSQL 类 型 。 


Oracle 类 型 
CHAR 
NCHAR 
VARCHAR 
VARCHAR? 
NVARCHAR? 
CLOB 
LONG 
RAW 
BLOB 
BFILE 
LONG RAW 
NUMBER 


NUMBER(n,m) (其 中 ,m 志 0) 


表 13-1 


展 或 者 用 户 手工 做 一 些 映射 。 表 13-1 给 出 了 类 型 如 何 被 映射 的 概览 ， 左 边 的 列 显示 的 是 


PostgreSQL 类 型 
char、varchar 和 text 


char、varchar 和 text 


char、varchar 和 text 


char、varchar 和 text 


char、varchar 和 text 


char、varchar 和 text 


char、varchar 和 text 


uuid 和 bytea 
bytea 
bytea (只 读 ) 
bytea 





numeric、float4、 


float8、char、 


varchar 和 text 


numeric 、float4 、float8 、int2 、int4 、int8 、boolean 、 
char、varchar 和 text 





FLOAT 


numeric 、float4、 


float8 、char、 


varchar 和 text 





BINARY _ FLOAT 
BINARY _ DOUBLE 


numeric、float4、 


numeric、float4、 


float8 、char、 
float8 、char、 


varchar 和 text 
varchar 和 text 














DATE date、timestamp、timestamptz、char、varchar 和 text 
TIMESTAMP date、timestamp、timestamptz、char、varchar 和 text 
TIMESTAMP WITH TIME ZONE date、timestamp、timestamptz、char、varchar 和 text 
TIMESTAMP WITH LOCAL TIME ZONE | date、 timestamp、timestamptz、char、varchar 和 text 
INTERVAL YEAR TO MONTH interval 、char、varchar 和 text 
INTERVAL DAY TO SECOND interval 、char、varchar 和 text 





MDSYS.SDO _ GEOMETRY 


geomel 
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如 果 用 户 想 用 几何 数据 ， 应 确保 数据 库 服务 器 中 安装 了 PostGIS 。 
oracle fdw 扩展 的 缺点 也 很 明显 ， 它 无 法 迁移 内 建 的 过 程 。 存 储 过 程 有 点 特殊 ， 它 们 
的 迁移 需要 一 些 人 工 介入 。 


13.2.2 ”使 用 ora2pg 从 Oracle 迁移 








在 外 部 数据 包装 器 存在 之 前 ， 就 已 经 有 人 在 从 Oracle 迁移 到 PostgreSQL。 高 昂 的 许 
可 证 开销 折磨 了 人 们 很 长 时 间 ， 因 此 迁移 到 PostgreSQL 也 变 成 了 一 种 很 自然 的 事情 。 

还 有 一 种 可 替代 oracle fdw 扩展 的 东西 名 为 ora2pg， 它 已 经 存在 了 很 多 年 并 且 可 以 
从 https://github.com/darold/ora2pg 免费 下 载 。ora2pg 使 用 Perl 编写 ， 并 且 长 期 都 有 新 版 本 








ora2pg 所 提供 的 特性 令 人 震惊 : 


完整 的 数据 库 模 式 迁 移 ， 包 括 表 、 视 图 、 序 列 和 索引 唯一、 主键 、 外 键 和 检 
查 约 束 ) 。 

用 户 和 组 的 特权 迁移 。 

分 区 表 的 迁移 。 

导出 预定 义 函数 、 触 发 器 、 过 程 、 包 以 及 包 主 体 。 

完整 或 部 分 数据 的 迁移 〈 使 用 WHERE 子 句 ) 。 

用 PostgreSQL 的 bytea 完整 支持 Oracle 的 BLOB 对 象 。 

将 Oracle 视图 导出 为 PostgreSQL 的 表 。 

导出 Oracle 的 用 户 定 义 类 型 。 

PL/SQL 代码 到 PL/pgSQL 代码 的 基本 自动 转换 。 所 有 东西 的 完整 自动 转换 是 不 
可 能 实现 的 。 不 过 ， 有 很 多 东西 可 以 被 自动 转换 。 

将 Oracle 表 导 出 为 外 部 数据 包装 器 表 。 

导出 物化 视图 。 
显示 Oracle 数据 库 内 容 的 详细 报告 。 

评估 一 个 Oracle 数据 库 的 迁移 过 程 的 复杂 度 。 

对 来 自 文件 的 PL/SQL 代码 的 迁移 代价 评估 。 

生成 可 用 于 Pentaho 数据 集成 器 (Kettle) 的 XML 文件 的 能 
将 Oracle 的 定位 器 或 者 空间 几何 导出 到 PostGIS。 

将 数据 库 链 接 导出 为 Oracle FDW。 

将 同义词 导出 为 视图 。 

将 目录 导出 为 一 个 外 部 表 或 者 用 于 external file 扩展 的 目录 。 
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@ 将 一 个 SQL 命令 列表 分 发 到 多 个 PostgreSQL 连接 。 
@ 在 Oracle 和 PostgreSQL 数据 库 之 间 执 行 di 和 进行 测 试 。 
使 用 ora2pg 乍 一 看 很 难 ， 但 实际 上 比 看 起 来 更 加 容易 。 基 本 的 用 法 如 下 : 


/usr/local/bin/ora2pg -c /some path/new ora2pg.conf 

ora2pg 需要 一 个 配置 文件 来 运行 。 该 配置 文件 包含 处 理 该 过 程 需 要 的 所 有 信息 。 基 
本 上 ， 默 认 的 配置 文件 其 实 已 经 很 好 了 ， 用 它 可 以 完成 大 部 分 的 迁移 。 在 ora2pg 的 语言 
中 ， 一 次 迁移 就 是 一 个 项 目 。 

这 个 配置 将 会 驱动 整个 项 目 。 在 用 户 运行 该 配置 时 ，ora2pg 将 用 从 Oracle 提取 的 所 
有 数据 创建 若干 个 目录 : 


ora2pg --project base /app/migration/ --init project test project 





Creating project test project. 
/app/migration/test project/ 

schema/ 
dblinks/ 
directories/ 
functions/ 
grants/ 
mviews/ 
packages/ 
partitions/ 
procedures/ 
sequences/ 
synonyms/ 
tables/ 
tablespaces/ 
triggers/ 
types/ 
views/ 

sources/ 
functions/ 
mviews/ 
packages/ 
partitions/ 
procedures/ 
triggers/ 
types/ 

views/ 
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data/ 
config/ 
reports/ 


Generating generic configuration file 
Creating script export schema.sh to automate all exports. 
Creating script import all.sh to automate all imports. 


如 你 所 见 ， 有 一 些 脚本 会 被 生成 ， 它 们 只 需要 被 直接 执行 就 好 。 产 生 的 结果 数据 接 
下 来 就 可 以 被 很 好 地 导入 PostgreSQL 中 。 不 过 要 准备 好 更 改 各 处 的 过 程 ， 因 为 不 是 所 有 
的 东西 都 能 被 自动 地 迁移 ， 因 此 通常 还 会 需要 一 些 人 工 介 入 。 

13.2.3 ”常见 的 陷阱 

有 一 些 非 常 基本 的 语法 元 素 可 以 在 Oracle 中 工作 但 可 能 无 法 在 PostgreSQL 中 工作 。 
本 节 列 出 了 一 些 最 重要 的 部 分 。 当 然 ， 目 前 这 个 列表 并 不 完整 ， 但 是 它 能 够 给 读者 指明 
正确 的 方向 。 

在 Oracle 中 ， 用 户 可 能 会 用 到 下 面 的 语句 : 

DELETE mytable; 

在 PostgreSQL 中 这 一 语句 是 错误 的 ， 因 为 PostgreSQL 要 求 用 户 在 DELETE 语句 中 
使 用 FROM 子 句 。 好 消息 是 这 类 语句 很 容易 修复 。 

下 一 种 可 能 碰 到 的 语句 是 : 

SELECT sysdate FROM dual; 

PostgreSQL 既 没有 sysdate 函数 也 没有 dual 函数 。dual 函数 部 分 比较 容易 修复 ， 因 为 
用 户 可 以 简单 地 创建 一 个 返回 单行 的 视图 来 模拟 。 在 Oracle 中 ，dual 函数 的 用 法 如 下 : 


SQL> desc dual 
Name Null? Type 




















DUMMY VARCHAR2 (1) 
SQL> select * from dual; 
D 


xX 
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在 PostgreSQL 中 ， 可 以 通过 创建 下 面 的 视图 实现 同样 的 效果 : 
CREATE VIEW dual AS SELECT 'X' AS dummy; 


sysdate 函数 也 很 容易 对 付 ， 可 以 用 clock_timestamp 函数 蔡 换 它 。 

另 一 种 常见 的 问题 是 缺少 varchar2 之 类 的 数据 类 型 以 及 只 有 Oracle 支持 的 特殊 函 
数 。 解 决 这 些 问 题 的 一 种 好 的 做 法 是 安装 orafce 扩展 ， 它 提供 了 通常 所 需 的 大 部 分 这 类 
东西 。 因 此 当然 有 必要 去 看 看 https://github.com/orafce/orafce 以 了 解 更 多 有 关 orafce 扩展 
的 情况 。 它 已 经 出 现 了 多 年 并 且 是 一 种 稳定 的 软件 。 最 近 进 行 的 一 项 研究 (由 NTT 完 
成 ) 表明 orafce 扩展 能 够 帮助 确保 所 有 Oracle SQL 中 的 73% 能 在 PostgreSQL 中 不 加 修改 
地 执行 。 

最 常见 的 陷阱 之 一 是 Oracle 处 理 外 连接 的 方式 。 考 虑 下 面 的 例子 : 


SELECT employee id, manager id 























FROM employees 
WHERE employees.manager id(+) = employees.employee id; 
PostgreSQL 没有 提供 这 类 语法 并 且 永 远 也 不 会 提供 。 因 此 这 个 连接 必须 被 重 写 为 正 
确 的 外 连接 。 加 号 (+) 是 与 Oracle 高 度 相关 的 元 素 ， 在 迁移 时 必须 把 它 移 除 。 


13.3 从 MySQL 或 MariaDB 转移 到 PostgreSQL 


在 本 章 中 ， 读 者 已 经 学 到 了 一 些 如 何 从 Oracle 等 数据 库 中 转移 到 PostgreSQL 的 方 
法 。 将 两 种 数据 库 系 统 ? 迁 移 到 PostgreSQL 都 很 容易 。 这 样 做 的 原因 是 Oracle 可 能 比较 
昂贵 并 且 Oracle 可 能 有 时 显得 有 些 策 重 ， 对 于 Informix 也 是 如 此 。 不 过 ，Informix 和 
Oracle 都 有 一 个 重要 的 共同 点 : CHECK 约束 会 被 正确 地 对 待 并 且 数 据 类 型 会 被 恰当 地 处 
理 。 通 常用 户 可 以 放心 地 认为 这 些 商 业 系 统 中 的 数据 是 正确 的 且 不 会 违背 基本 的 数据 完 
整 性 规则 和 常识 。 

接 下 来 的 数据 库 系统 有 点 不 同 。 我 们 从 商业 数据 库 中 了 解 到 的 很 多 事情 在 MySQL 中 
都 不 一 样 。NOT NULL 对 于 MySQL 并 没有 什么 意义 (除非 用 户 明 确 地 使 用 严格 模 
式 ) 。 在 Oracle、Informix、DB2 和 所 有 笔者 知道 的 其 他 系统 中 ，NOT NULL 都 是 一 条 铁 
律 ， 它 在 所 有 环境 下 都 会 被 遵从 。 而 MySQL 默认 并 不 把 这 类 约束 当 回 事 ， 在 迁移 时 这 就 
会 导致 一 些 问 题 。 对 于 技术 上 错误 的 数据 我 们 能 做 些 什么 ?如 果 突 然 发 现 NOT NULL 列 
中 有 无 数 的 空 项 ， 应 该 怎样 处 理 ? MySQL 并 不 只 是 在 NOT NULL 列 中 插入 空 值 。 它 会 
根据 数据 类 型 插入 一 个 空 字符 串 或 者 0。 这 样 ， 事 情 就 很 令 人 烦恼 了 。 






































9 这 里 原文 似乎 有 点 问题 ， 作 者 本 意 应 该 是 指 Oracle 和 Informix 两 种 数据 库 系统 ， 但 是 在 此 之 前 还 未 提 到 Informix。 
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13.3.1 处 理 MySQL 和 MariaDB 中 的 数据 


正如 读者 可 能 想象 或 者 已 经 注意 到 的 ， 在 谈论 到 具体 数据 库 时 笔者 似乎 变 得 不 那么 
公正 了 。 不 过 ， 笔 者 并 不 想 把 这 一 部 分 内 容 变 成 对 MySQL/MariaDB 的 盲目 择 击 。 笔 者 的 
目的 实际 上 是 向 读者 展示 为 什么 MySQL 和 MariaDB 可 能 在 长 期 运行 中 为 用 户 带 来 痛 
苦 。 笔 者 的 偏向 是 有 原因 的 ， 并 且 笔 者 真 地 想 指出 为 什么 会 这 样 。 接 下 来 读者 将 看 到 的 
事情 很 吓人 并 且 通 常 对 迁移 过 程 有 严重 的 影响 。 笔 者 已 经 指出 过 MySQL 有 点 特殊 ， 本 节 
将 会 尝试 证 明 这 一 观点 。 

让 我 们 从 创建 一 个 简单 的 表 开 始 : 

MariaDB [test]> CREATE TABLE data ( 


id integer NOT NULL, 
data numeric(4, 2) 





); 
Query OK, 0 rows affected (0.02 sec) 


MariaDB [test]> INSERT INTO data VALUES (1, 1234.5678); 
Query OK, 1 row affected, 1 warning (0.01 sec) 


到 目前 为 止 ， 没 什么 特殊 的 事情 。 笔 者 创建 了 一 个 由 两 列 构 成 的 表 。 第 一 列 被 明确 
地 标记 为 NOT NULL。 第 二 列 被 假定 为 包含 长 度 为 四 位 的 数字 值 。 最 后 ， 笔 者 还 增加 了 
一 个 简单 的 行 。 不 知道 读者 能 否 看 到 这 里 有 一 个 将 要 被 触发 的 地 雷 ? 很 可 能 看 不 出 来 。 
没关系 ， 检 查 下 面 的 列表 : 

MariaDB [test]> SELECT * FROM data; 

+ 一 一 一 十 一 一 一 一 一 一 一 + 

aa li aatay ll 

二 一 一 一 一 十 一 一 一 一 一 一 一 + 

a S998al 

二 -一 一 一 + 一 一 一 一 一 一 一 

1 row in set (0.00 sec) 


如 果 笔 者 没有 记 错 ， 刚 才 增 加 的 是 一 个 四 位 数 ， 但 首先 它 就 没有 产生 效果 。MariaDB 
直接 更 改 了 笔者 的 数据 。 当 然 ， 它 发 出 了 一 个 警告 ， 但 是 这 确实 不 应 该 发 生 ， 因 为 表 的 
内 容 并 未 反映 笔者 实际 插入 的 东西 。 

让 我 们 尝试 在 PostgreSQL 中 做 同样 的 事 ; 

test=# CREATE TABLE data ( 

id integer NOT NULL, 





焉 


百 : 
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错 ， 


data numeric(4, 2) 
); 
CREATE TABLE 
test=# INSERT INTO data VALUES (1, 1234.5678); 
ERROR: numeric field overflow 
DETAIL: A field with precision 4, scale 2 must round to an absolute value 
less than 10^2. 


表 的 创建 和 前 面 一 样 ， 但 与 MariaDB/MySQL 形成 鲜明 对 比 的 是 ，PostgreSQL 将 会 报 
因为 我 们 尝试 将 一 个 不 被 允许 的 值 插 入 表 中 。 如 果 数 据 库 引擎 根本 不 在 乎 ， 清 晰 地 





定义 我 们 想 要 什么 还 有 何 意义 ? 假设 你 赢得 彩票 ， 但 却 损 失 了 几 百 万 ， 只 是 因为 系统 觉 
得 那 对 你 比较 好 ， 你 会 怎么 想 ? 


笔者 的 整个 职业 生涯 都 在 与 商业 数据 库 斗 争 ， 但 笔者 从 未 在 任何 昂贵 的 商业 系统 





(Oracle、DB2、MS SQL 等 ) 中 见 过 类 似 的 事情 。 它 们 可 能 都 有 自身 的 问题 ， 但 是 至 少 
通常 数据 是 正确 的 。 


住 ， 


1， 更 改 列 定义 
让 我 们 看 看 如 果 想 要 修改 表 定义 会 发 生 什么 : 


MariaDB [test]> ALTER TABLE data MODIFY data numeric(3, 2); 
Query OK, 1 row affected, 1 warning (0.06 sec) 
Records: 1 Duplicates: 0 Warnings: 1 


看 出 这 里 的 问题 了 吗 ? 


MariaDB [test]> SELECT * FROM data; 
+ 一 一 一 二 一 一 一 一 一 一 十 
Vaid laata 1 


1 row in set (0.00 sec) 


如 你 所 见 ， 数 据 又 被 修改 了 。 原 本 它 就 不 应 该 在 这 里 ， 而 在 这 里 又 一 次 被 更 改 。 记 
你 可 能 再 次 损失 金钱 或 者 其 他 一 些 资产 ， 只 是 因为 MySQL 自作 聪明 。 

PostgreSQL 中 是 这 样 的 : 

test=# INSERT INTO data VALUES (1, 34.5678); 


INSERT 0 1 
test=# SELECT * FROM data; 
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1 1 3457 


(1 row) 
现在 让 我 们 更 改 列 定义 : 
test=# ALTER TABLE data ALTER COLUMN data TYPE numeric(3, 2); 


ERROR: numeric field overflow 
DETAIL: A field with precision 3, scale 2 must round to an absolute value 


less than 10^1. 

PostgreSQL 将 再 次 报错 并 且 不 允许 对 数据 做 不 好 的 事情 。 在 任何 重要 的 数据 库 中 都 
预期 会 发 生 同样 的 事情 。 规 则 很 简单 : PostgreSQL 和 其 他 的 数据 库 将 不 允许 用 户 毁 掉 他 
们 的 数据 。 

不 过 ，PostgreSQL 人 允许 用 户 做 一 件 事情 : 

test=# ALTER TABLE data 

ALTER COLUMN data 
TYPE numeric(3, 2) 
USING (data / 10); 

ALTER TABLE 

用 户 可 以 明确 地 告诉 系统 如 何 行动 。 在 这 个 例子 中 ， 笔 者 明确 地 告诉 PostgreSQL 把 
该 列 的 内 容 除 以 10。 开 发 者 们 可 以 明确 地 提供 适用 于 数据 的 规则 。PostgreSQL 不 会 自作 
聪明 ， 并 且 它 有 充分 的 理由 这 样 做 : 


test=# SELECT * FROM data; 














id | data 
二 
1 1 3.46 
(1 row) 
可 以 看 到 数据 是 符合 预期 的 。 
2， 处 理 空 值 


笔者 并 不 想 把 本 章 变 成 “为 什么 MariaDB 不 好 ”， 但 笔者 想 要 在 这 里 给 出 最 后 一 个 
例子 ， 笔 者 认为 它 很 重要 : 
MariaDB [test]> UPDATE data SET id = NULL WHERE id = 1; 


Query OK, 1 row affected, 1 warning (0.01 sec) 
Rows matched: 1 Changed: 1 Warnings: 1 


“ 3256“ 
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记 住 ，id 列 被 明确 地 标记 为 NOT NULL: 


MariaDB [test 
二 十 
1 id | data | 


1 row in set 


]> SELECT * FROM data; 


(0.00 sec) 


显然 ，MySQL 和 MariaDB 认为 空 和 和 零 是 相同 的 东西 。 让 笔者 尝试 用 一 个 简单 的 比喻 


来 解释 这 个 问题 : 


“你 知道 你 的 钱包 是 空 的 ”和 “我 不 知道 到 底 我 有 多 少 钱 ” 是 不 一 样 


的 。 在 笔者 写 这 一 部 分 内 容 时 ， 笔 者 不 知道 自己 有 多 少 钱 〈 空 = 未 知 ) ， 但 笔者 100% 肯 
定 不 是 零 〈 笔 者 敢 肯定 足够 在 从 机 场 回 家 的 路 上 给 笔者 可 爱 的 车 加 上 油 ， 但 口袋 里 什么 


都 没有 就 难 办 了 ) 。 








这 里 还 有 更 加 吓人 的 消息 : 

MariaDB [test]> DESCRIBE data; 

本 三 三 三 三 三 三 三 和 ==== == = 三 == 三 == 二 让 ======= + 
| Field | Type | Null | Key | Default | Extra | 
二 = 二 = 三 = 三 = = 二 ==== = 二 二 三 = 二 ====== 十 
Tia V int(11) | NO | | NULL 1 

| data | decimal(3,2) | YES | | NULL 1 

二 = 三 = 三 = = === == ;三 = 三 二 = 三 = 三 JE 三 = 三 = 二 | + 


2 rows in set (0.00 sec) 
MariaDB 确实 记得 列 被 假定 为 空 ， 但 它 又 一 次 更 改 了 用 户 的 数据 。 
3， 预 期 的 问题 





主要 的 问题 是 将 数据 转移 到 PostgreSQL 时 可 能 会 有 麻烦 。 想 象 一 下 ， 用 户 想 要 转移 


一 些 数 据 并 且 在 PostgreSQL 端 有 一 个 NOT NULL 约束 。 我 们 知道 MySQL 根本 不 在 乎 : 


MariaDB [test]> SELECT CAST('2014-02-99 10:00:00' RS datetime) RS x, 
CAST('2014-02-09 10:00:00' RS datetime) AS y; 


+—-- 一 一 一 二 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 + 
| 3 Me 1 
+-- 一 一 一 二 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 + 
| NULL | 2014-02-09 10:00:00 1 
二 -一 一 一 一 一 二 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 + 


1 row in set, 


1 warning (0.00 sec) 
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PostgreSQL 肯定 将 会 拒绝 2 月 99 日 (有 充分 的 理由 ) ， 但 是 它 可 能 也 不 会 接受 空 值 
(如 果 已 经 明确 地 禁止 空 值 ， 也 有 充分 的 理由 ) 。 这 种 情况 下 用 户 必 须 做 的 是 修复 数据 
以 确保 它 遵循 数据 模型 的 规则 〈 由 于 某 种 原因 已 经 存在 ) 。 用 户 不 应 该 对 此 掉以轻心 ， 
因为 用 户 可 能 不 得 不 更 改 数据 ， 而 这 些 数据 实际 上 原本 就 是 错误 的 。 


13.3.2 ”迁移 数据 和 模式 


在 尝试 解释 为 什么 转移 到 PostgreSQL 是 一 种 好 主意 并 且 描 述 一 些 最 重要 的 问题 之 
后 ， 现 在 是 时 候 看 看 我 们 有 些 什 么 选项 可 以 最 终 完成 从 MySQL/MariaDB 迁移 的 工作 。 























1. 使 用 pg_chameleon 


一 种 从 MySQL/MariaDB 转移 到 PostgreSQL 的 方法 是 使 用 Federico Campoli 开发 的 
pg_chameleon 工具 ， 它 可 以 从 GitHub 自由 下 载 : https://github.comy/the4thdoctor/pg_chameleon。 
该 工具 被 明确 地 设计 为 将 数据 复制 到 PostgreSQL 中 并 且 为 用 户 做 很 多 转换 模式 之 类 的 工作 。 

基本 上 ， 该 工具 会 执行 下 面 的 4 个 步骤 : 

(1) pg_chameleon 从 MySQL 读 取 模式 和 数据 ， 并 且 在 PostgreSQL 中 创建 一 个 方案 。 
(2) 在 PostgreSQL 中 保存 MySQL 的 主 连接 信息 。 

(3) 在 PostgreSQL 中 创建 主键 和 索引 。 

(4) 从 MySQL/MariaDB 复制 到 PostgreSQL。 

pg_chameleon 提供 对 DDL 的 基本 支持 ， 例 如 CREATE、DROP、ALTER TABLE、 
DROP PRIMARY KEY 等 。 不 过 ， 由 于 MySQL/MariaDB 本 身 的 原因 ， 它 不 支持 所 有 的 
DDL， 但 好 在 它 涵盖 了 最 重要 的 特性 。 

然而 ，pg_chameleon 并 不 仅 如 此 。 笔 者 已 经 全 面 地 阐述 了 数据 并 不 总 是 像 它 应 该 的 
那样 或 者 所 预期 的 那样 。pg_chameleon 解决 这 一 问题 的 方法 是 抛弃 垃圾 数据 并 且 把 它 存 
储 在 一 个 名 为 sch_chameleon.t_discarded rows 的 表 中 。 当 然 ， 这 并 不 是 一 种 完美 的 方 
案 ， 但 是 对 于 给 定 的 质量 相当 低 的 输入 ， 这 是 笔者 唯一 能 想到 的 明智 的 方案 。 其 想法 是 
让 开发 者 决定 如 何 处 理 那 些 损 坏 的 行 。pg_chameleon 实在 没有 办 法 决定 如 何 处 理 那 些 被 
其 他 人 损坏 的 东西 。 

近来 ， 这 个 工具 又 进行 了 很 多 开发 工作 。 因 此 ， 推 荐 用 户 检 查 该 工具 的 GitHub 页 I 
并 且 通 读 所 有 的 文档 。 新 的 特性 和 缺陷 修复 持续 地 被 加 入 到 该 工具 中 ， 以 本 章 有 限 的 篇 
幅 实 在 不 可 能 完全 涵盖 所 有 的 内 容 。 

存储 过 程 、 触 发 器 等 需要 特殊 对 待 并 且 只 能 用 手工 处 理 ，pg_chameleon 无 
法 自动 处 理 这 些 东 西 。 
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2. 使 用 外 部 数据 包装 器 


如 果 用 户 想 要 从 MySQL/MariaDB 转移 到 PostgreSQL， 那 么 有 多 种 方法 可 以 完成 这 
一 工作 。 使 用 外 部 数据 包装 器 是 pg_chameleon 的 一 种 蔡 代 方案 ， 它 提供 了 一 种 快速 将 模 
式 和 数据 导入 PostgreSQL 中 的 途径 。 连 接 MySQL 和 PostgreSQL 的 功能 已 经 出 现 了 相当 
长 一 段 时 间 ， 因 此 探索 外 部 数据 包装 器 这 一 领域 绝对 对 读者 有 帮助 。 

说 穿 了 ，mysql fdw 扩展 和 任何 其 他 FDW 的 效果 相似 。 相 对 于 其 他 知名 度 较 低 的 
FDW 来 说 ，mysql_fdw 扩展 确实 非常 强大 并 且 提 供 了 下 列 特 性 : 

@ 为 MySQL/MariaDB 编写 。 

@ 连接 池 。 

@ WHERE 子 句 下 推 (这 意味 着 应 用 在 表 上 的 过 滤 条 件 可 以 真正 地 在 远 端 被 执行 ， 

这 样 性 能 更 好 ) 。 
@ 列 下 推 ( 只 有 需要 的 列 才 从 远 端 取得 ， 较 老 的 版 本 习惯 于 取得 所 有 的 列 ， 这 样 
会 导致 更 多 的 网 络 流量 ) 。 

@ 远 端 预备 语句 。 

使 用 mysql_fdw 扩展 的 方式 是 利用 IMPORT FOREIGN SCHEMA 语句 ， 它 允许 把 数 
据 转移 到 PostgreSQL 上 去 。 

幸运 的 是 ， 这 在 Unix 系统 上 很 容易 做 到 。 

要 做 的 第 一 件 事情 是 从 GitHub 下 载 代码 : 

git clone https://github.com/EnterpriseDB/mysql fdw.git 

然后 运行 下 面 的 命令 编译 FDW。 注 意 在 读者 的 系统 上 路 径 可 能 会 不 同 。 对 于 本 章 的 
例子 ， 笔 者 假定 MySQL 和 PostgreSQL 都 位 于 /usr/local 目录 之 下 ， 但 在 读者 的 系统 上 可 
能 不 是 这 样 : 

$ export PATH=/usr/local/pgsql/bin/:$PATH 

$ export PATH=/usr/local/mysql/bin/:$PATH 

$ make USE PGXS=1 

$ make USE PGXS=1 install 


一 旦 代码 被 编译 好 ， 就 可 以 把 FDW 加 入 数据 库 中 : 
CREATE EXTENSION mysql fdw; 
下 一 步 是 建立 想 要 迁移 的 服务 器 : 


CREATE SERVER migrate me server 
FOREIGN DATA WRAPPER mysql fdw 
OPTIONS (host 'host.example.com', port '3306'); 
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一 旦 服务 器 被 创建 好 ， 就 可 以 建立 想 要 的 用 户 映射 : 


CREATE USER MAPPING FOR postgres 
SERVER migrate me server 











OPTIONS (username 'joe', password "public'): 


最 后 就 是 做 实际 的 迁移 。 其 中 的 第 一 个 工作 是 导入 模式 。 笔 者 建议 首先 为 被 链接 的 
表 创 建 一 个 特殊 的 方案 : 


CREATE SCHEMA migration schema; 


在 运行 IMPORT FOREIGN SCHEMA 语句 时 ， 可 以 把 这 个 方案 用 作 目 标 方案 ， 所 有 
的 数据 库 链 接 都 将 被 存储 在 其 中 。 这 样 做 的 好 处 是 在 迁移 后 可 以 很 方便 地 删除 它 。 

执行 完 IMPORT FOREIGN SCHEMA 语句 之 后 ， 就 可 以 开始 创建 真正 的 表 。 最 简单 
的 方法 是 使 用 CREATE TABLE 子 句 提供 的 LIKE 关键 词 。 它 允许 用 户 复制 一 个 表 的 结构 
并 且 创 建 一 个 真正 的 本 地 PostgreSQL 表 。 幸 运 的 是 ， 当 正在 克隆 的 表 是 一 个 外 部 数据 包 
装 器 时 也 能 这 样 做 。 例 如 : 


CREATE TABLE t customer 
(LIKE migration schema.t_ customer); 


然后 就 可 以 处 理 数据 : 


INSERT INTO t customer 
SELECT * FROM migration schema.t customer 


这 里 实际 上 就 是 用 户 改正 数据 、 消 除 大 量 行 或 者 做 一 点 数据 处 理 的 时 机 。 对 于 质量 
低下 的 数据 源 ， 在 第 一 次 转移 数据 之 后 应 用 约束 等 可 能 会 有 所 帮助 ， 这 样 做 可 能 不 那么 
痛苦 。 在 适当 的 数据 库 中 ， 可 能 有 必要 采用 相反 的 过 程 。 

一 旦 数据 被 导入 ， 用 户 就 可 以 部 署 所 有 的 约束 、 索 引 等 。 正 如 笔者 之 前 陈述 的 ， 从 这 
里 开始 用 户 将 会 开始 真正 碰 到 一 些 让 人 不 快 的 “惊喜 ”， 所 以 不 要 指望 数据 是 可 靠 的 。 











13.4 总 结 


本 章 读 者 学 习 了 如 何 转移 到 PostgreSQL。 迁 移 是 一 个 非常 重要 的 主题 ， 因 为 就 在 我 
们 谈论 这 些 内 容 时 ， 越 来 越 多 的 人 们 已 经 开始 采用 PostgreSQL。 


